phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [phpGroupWare-developers] Google Summer of Code


From: Christian Rost
Subject: Re: [phpGroupWare-developers] Google Summer of Code
Date: Tue, 17 Apr 2007 15:26:30 +0200
User-agent: Thunderbird 1.5.0.9 (Windows/20061207)

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.
> 
Well, the Funambol Server has the advantage, that you needn't to think about 
the SyncML and
synchronisation stuff, because they did it already. In general, the only thing 
vou've to do is
to create an interface for the Funambol Server to read, update and write 
contacts or
appointments within phpGroupWare. In addition they added some features to 
manage mobile devices,
but I didn't check that out, yet.

Oh btw, yesterday I read an article about Zarafa [http://www.zara.com/], going 
to make their PHP
based Active-Sync connector "AirSync" OpenSource. You can watch the video 
stream in english
under 
http://www.linux-magazin.de/videos/zarafa_opensource_airsync/(kategorie)/343. 
One could
keep this in mind for later.


> 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.
> 
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.

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.

> 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.
> 
> --Johan

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.


Christian

-- 
===========================================================
Christian Rost
roCon - Informationstechnologie
Glatzer Weg 4

44534 Lünen

fon: +49 (0) 2306 910 658
fax: +49 (0) 2306 910 664
url: http://www.rocon-it.de











reply via email to

[Prev in Thread] Current Thread [Next in Thread]