Re: [Evolution-hackers] Creating a new server type

On Wed, 2004-10-06 at 15:10 +0200, Thomas Cataldo wrote:

We (as me and Laurent Belmonte, the monkey bubble maintainer) are in the
process of writing e-book and e-cal backends for OBM, our company
web-based groupware/management solution. OBM is already GPLed and so
will the evolution connector.

Right now we have a working e-book backend, providing to ebooks, one for
the obm users, and one for the contacts (users have an obm login and
Sounds good.
To test our backend, we are using a separate executable doing some
e_source_new sorcery. We are aiming for a better integration : we want
"O.B.M." to be available in the "server type" list when we create a new

    g_print("*************** Trying to start camel provider for OBM **************\n");

    obm_provider.authtypes =
	g_list_prepend (NULL, &camel_obm_password_authtype);
    obm_provider.url_hash = obm_url_hash;
    obm_provider.url_equal = obm_url_equal;


You shoudlnt' re-bind-text-domain, as this will affect the rest of the application since this runs in the evolution memory space.  The translation domain thing is to provide translation mechanism for the strings in the provider table.
    obm_provider.translation_domain = GETTEXT_PACKAGE;

    camel_provider_register (&obm_provider);
This is all you need to register the type, but the only types which show up are ones which provide a store implementation.  So you need to at least provide a do-nothing store implementation, otherwise the provider is just skipped in the account configuration page, since that only shows actual stores you can get stuff from.  Remember camel is only for mail, so connector and the groupwise connector 'hack it' a bit to make it work to configure other things too.

Which version are you targeting?  Do you know that we are working on a new extensibility mechanism for evolution 2.2 that will let you hook into bits of evolution to do things like this better?  At the least it will let you add some new configuration buttons or a menu item where you can run your own separate "account configuration" system which will at least let you get something going, even if it isn't the neatest UI to do it.  But hacking it into the mail account druid isn't very neat either.

We're also contemplating a better account management system so you can create central info for use by all components, without having to hack it into something which was only ever designed for email.  But this is more work than we may have time for in the 2.2 timeframe.  i.e. a system which would let you create connector style accounts or and ldap addressbook or a mail account through the same frontend and stored in the same backend.

Michael Zucchi <notzed ximian com>
"born to die, live to work, it's all downhill from here"
Novell's Evolution and Free Software Developer

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