[Evolution-hackers] Creating a new server type
Not Zed
notzed@ximian.com
Wed, 06 Oct 2004 21:44:26 +0800
--=-YB648nyQp+eumEJoobzc
Content-Type: multipart/alternative; boundary="=-oWp3YxXyQRnV6G/Q9Rt+"
--=-oWp3YxXyQRnV6G/Q9Rt+
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
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
--=-oWp3YxXyQRnV6G/Q9Rt+
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.2.2">
</HEAD>
<BODY>
On Wed, 2004-10-06 at 15:10 +0200, Thomas Cataldo wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi,</FONT>
<FONT COLOR="#000000">We (as me and Laurent Belmonte, the monkey bubble maintainer) are in the</FONT>
<FONT COLOR="#000000">process of writing e-book and e-cal backends for OBM, our company</FONT>
<FONT COLOR="#000000">web-based groupware/management solution. OBM is already GPLed and so</FONT>
<FONT COLOR="#000000">will the evolution connector.</FONT>
<FONT COLOR="#000000">Right now we have a working e-book backend, providing to ebooks, one for</FONT>
<FONT COLOR="#000000">the obm users, and one for the contacts (users have an obm login and</FONT>
<FONT COLOR="#000000">calendar).</FONT>
</PRE>
</BLOCKQUOTE>
Sounds good.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">To test our backend, we are using a separate executable doing some</FONT>
<FONT COLOR="#000000">e_source_new sorcery. We are aiming for a better integration : we want</FONT>
<FONT COLOR="#000000">"O.B.M." to be available in the "server type" list when we create a new</FONT>
<FONT COLOR="#000000">account.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> </FONT>
<FONT COLOR="#000000"> g_print("*************** Trying to start camel provider for OBM **************\n");</FONT>
<FONT COLOR="#000000"> obm_provider.authtypes =</FONT>
<FONT COLOR="#000000"> g_list_prepend (NULL, &camel_obm_password_authtype);</FONT>
<FONT COLOR="#000000"> obm_provider.url_hash = obm_url_hash;</FONT>
<FONT COLOR="#000000"> obm_provider.url_equal = obm_url_equal;</FONT>
<FONT COLOR="#000000"> bindtextdomain (GETTEXT_PACKAGE, CONNECTOR_LOCALEDI</FONT>R);
</PRE>
</BLOCKQUOTE>
<BR>
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.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> obm_provider.translation_domain = GETTEXT_PACKAGE;</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> camel_provider_register (&obm_provider);</FONT>
</PRE>
</BLOCKQUOTE>
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.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
<TABLE CELLSPACING="6">
<TR>
<TD>
<IMG SRC="cid:1097069367.10191.46.camel@lostzed.mmc.com.au" WIDTH="48" HEIGHT="48" ALIGN="top" ALT="" BORDER="0">
</TD>
<TD>
<B>Michael Zucchi</B> <<A HREF="mailto:notzed@ximian.com">notzed@ximian.com</A>><BR>
<I>"born to die, live to work, it's all downhill from here"</I><BR>
<TT>Novell's <A HREF="http://codeblogs.ximian.com/blogs/evolution/">Evolution</A> and <A HREF="http://www.gnu.org/philosophy/free-sw.html">Free Software</A> Developer</TT>
</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>
--=-oWp3YxXyQRnV6G/Q9Rt+--
--=-YB648nyQp+eumEJoobzc
Content-ID: <1097069367.10191.46.camel@lostzed.mmc.com.au>
Content-Disposition: attachment; filename=zed-48.small.jpg
Content-Type: application/octet-stream; name=zed-48.small.jpg
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAA0JCgsKCA0LCgsODg0PEyAVExISEyccHhcgLikxMC4p
LSwzOko+MzZGNywtQFdBRkxOUlNSMj5aYVpQYEpRUk//2wBDAQ4ODhMREyYVFSZPNS01T09PT09P
T09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0//wAARCAAwADADASIA
AhEBAxEB/8QAGQAAAwEBAQAAAAAAAAAAAAAAAwQFAgYB/8QALhAAAgEDAgUEAQIHAAAAAAAAAQID
BBEhABIFEzFBURQigZEGYXE0UmJyobHx/8QAFwEBAQEBAAAAAAAAAAAAAAAABAMCAf/EAB0RAAID
AQEAAwAAAAAAAAAAAAABAgMREjEiMkH/2gAMAwEAAhEDEQA/AK8sEEq35nLaP3e1cW/m8kfdtAfh
824L7I1YFrnaRt8+L40U1ECxiGjLzSCocRYuQhubW7jIxrcFZRzU7q3sh3e8deWvX67/AKX0Xegi
TixevoZdxjhnkk2xBj2Z7DIA74Gs+kgpoaamPLllqE5yPuO4i1+nix7+NS3qatikPNZa+idmjLGx
YE+7r16DHgnTEtRWTVIraiknUrE42mJvYTY/IyfjT66YZjNzkzSSRTrEYTuz0tbpg6oV1V62op5G
3QhV9yn+7t8DXPDiZlaepq0AYIBGEFtuRc2/WwH7aroXho98jNG5RVa4wDYNbzqNsefqdcnmM0J0
pp1kKyRywsdpU46EX/19aT4ioWgmanATG0Mpvcd89750arjMg2L1DfQtnSixTMW5hO0ZBZsEg5t5
xodU+8fhit7jZz4ChQWS99U1lC0H8RNZx74xK2DkAG48ePOtU0UUsQLC6kki/wC+jqtMpeLapjYg
XJyNLcxyr1EUHaWaEspHXPbXVcNkUcCUOjvNv2kAdAehOkVo4LrDEFG9hcnPe+rlUsNNSenUIWkk
ZHfbflqFC475IvqdnyWaRsgl6MNwysp13y8uLG3cTk6LBwCmliFR6lw7XBKdMdj50t+X8RkWOnhV
rbnLfX/dUPx1ivAoTJnmFm+CdIVEIx6XpFQSZxVVH6KrkRRaAudn9I8HXhniSPcyC/ntqzxOjMNS
6uNyMbqT0I1Ogoad6pF5S23C4t1zqOa8Y7xbEDSxmesguHDId4DKQDjGqMqHmNLGygFnujAZF8DF
820/xYpQ8RWcRLtkBINuh6Ef5B0tNRH0L7UEjGzCVTZirDBGfJ+NasrcMf4CnLp6f//Z
--=-YB648nyQp+eumEJoobzc--