On Tue, 2010-03-23 at 18:25 +0100, Patrick Ohly wrote: It turned out that this was exactly Uwe's intention. So here's what we do to add a new server template to the upstream SyncEvolution (src/README.templates in the current development version): The configuration templates in "templates" get installed into $(datadir)/syncevolution/templates. When adding/changing a new server, then only enter the properties which need to be changed here so that the default values can be used for the remaining properties. An icon can be added here for servers. The file name must start with "icon". Server configurations must be kept in sync in three different places: - here (if a server is installed as files) - in SyncEvolutionConfig.cpp's EvolutionSyncConfig::createServerTemplate() - in SyncEvolutionCmdline.cpp's test server configs - in test/test-dbus.py testGetConfigsTemplates() Note that server icons must come with a suitable license that allows redistribution. Creating a server entry as files is only useful when it comes with an icon. None of the current templates has one, because we don't have suitable icons (can't just copy a random file from a web site) and we might run into trademark issues. If there was an icon, it would be shown by the sync-ui instead of the generic one. We'll accept pretty much any template as long as it doesn't set the "consumerReady" flag. Templates with that flag are the ones that show up in the sync-ui, and for those we have additional requirements: * Service should be available for normal users, if possible permanently (paid or for free). Time-limited demo servers like my.funambol.com are corner cases, marked with "Demo" in the description. * The sync-ui binary contains localized descriptions of some services. We would need something like that for new services. * SyncEvolution users of that service should get support from the operator. For us that means that we need a technical contact, ideally someone who has an account on bugzilla.moblin.com (soon bugzilla.meego.com) so that we can assign issues to him. * Someone should do at least some minimal interoperability testing, ideally using "client-test". Right now, the resources of the core SyncEvolution team are not sufficient to take on that testing for more services. If we get test accounts, we can add the server to our nightly testing and send a copy of each nighly test report to the operator. It doesn't really matter whether the service is free (both as in beer and in freedom) or closed/commercial. The reason why SyncEvolution supports commercially operated services better is only because those tend to provide the necessary support. If someone wants to have his favorite open source services supported and can meet the requirements above, we'd be more than happy to assist. There's already an issue open for eGroupware: http://bugzilla.moblin.org/show_bug.cgi?id=5631 -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Pützstr. 5 Phone: +49-228-2493652 53129 Bonn Germany