On Tue, 2010-03-23 at 18:25 +0100, Patrick Ohly wrote:
> But why do you want to add a template? That's only useful when you
> intend to configure that server multiple times.
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
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
