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 _______________________________________________ phpGroupWare-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
