Re: [phpGroupWare-developers] Google Summer of Code

[Dave Hall]

On Tue, 2007-04-17 at 15:26 +0200, Christian Rost wrote:
> Johan Gunnarsson schrieb:
> > Hi,
> > 
> > Thanks for your input. My project is supposed to be a native PHP
> > implementation, but I'm of course open for discussions. I know some
> > Java so switching to making a connector for Funambol is an option
> > worth dicussing.
> 

The final implementation is not set in concrete, but I think that the
php native implementation is more likely to succeed and be maintainable
within the project with our own resources.

> 
> > I personally have a feeling a PHP implementation would the best
> > solution in the end. Running a Funambol a instance, which I guess is
> > somewhat heavy and requires more of the server and admin. I'm talkning
> > about running an app server and together with all configuration that
> > comes with such a beast. You seem to have experience in setting up and
> > manage a Funambol installation. What are your thoughts about it? I
> > think running a PHP implementation would be a lot smoother and more
> > admin-friendly.
> > 

I support this too.  Installing funambol is not something that is
straight forward and getting the infrastructure for it from any non
dedicated hosting is very unlikely.

> Yeah, it is a beast to configure and it consumes a lot of RAM. During an 
> initial sync it takes
> up to 600 MB and unfortunately doesn't give it back when the sync is done. 
> Because we don't know
> much Java, we couldn't get a hold on it wether it's the server or the 
> connector that consumes so
> much RAM. But that's a problem you could easily deal with by buing more RAM.
> 

600M for a sync? that is insane.  You could easily DoS a box by running
a couple of syncs.

> Another problem is speed. SyncML is based on HTTP and therefore not an time 
> critical protocol,
> but the clients could have build in timeouts. If you're running phpGroupWare 
> with e.g. MySQL it
> is much faster than with the additional LDAP backend. Because LDAP lookups 
> take much longer than
> SQL queries, you have to keep it in mind when checking ACLs. As usual, if 
> we're talking about a
> small amount of items to sync, let's start with contacts and appointments, it 
> doesn't matter if
> it takes 5 or 15 milliseconds per lookup but it adds up to a quite a lot of 
> time with at least
> several hundreds or thousands items.
> 

Optimising and caching to improve performance is not something Johan
will be expected to work on, but it is something that I will be trying
to spend some time on as he identifies problems.

> > I knew Horde had an implementation compliant with SyncML 1.1 but I
> > didn't know I had been ported to another project. I will have to
> > investigate into how they did it.
> >
> Yeah, it might be a good start to investigate the eGroupWare SyncML 
> interface. I don't know how
> far you've already planned the coding of the SyncML interface, but I'm 
> willing to contribute and
> to test.

I have looked at the egw code - not just sync - and I don't think there
is a lot we can learn from them.

Cheers

Dave 
-- 
Dave Hall (aka skwashd)
API Coordinator
phpGroupWare
e address@hidden
w phpgroupware.org
j address@hidden
sip address@hidden
       _            ____                    __        __             
 _ __ | |__  _ __  / ___|_ __ ___  _   _ _ _\ \      / /_ _ _ __ ___ 
| '_ \| '_ \| '_ \| |  _| '__/ _ \| | | | '_ \ \ /\ / / _` | '__/ _ \
| |_) | | | | |_) | |_| | | | (_) | |_| | |_) \ V  V / (_| | | |  __/
| .__/|_| |_| .__/ \____|_|  \___/ \__,_| .__/ \_/\_/ \__,_|_|  \___|
|_|         |_|                         |_|Web based collaboration platform