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

[Not Zed <notzed ximian com>]

On Wed, 2004-10-06 at 15:10 +0200, Thomas Cataldo wrote:
> Hi,
>
> 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
> calendar).
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
> account.

>     
>     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;
>
>     bindtextdomain (GETTEXT_PACKAGE, CONNECTOR_LOCALEDIR);

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