Re: [Evolution-hackers] camel eds work progress

[Not Zed <notzed ximian com>]

Most of the listener stuff isn't configuration, its just something which runs all the time from startup (it is infact, entirely independent of it), I think anyway.  However, this would be trivial to move into an eplugin and just do the same from the a e_plugin_lib_enable() function rather than abusing the camel_provider_module_init function.

But this may affect the use of the resources only from eds, i.e. if you try to add an account without evolution going (but in reality you can't do this).

The whole camel provider could be moved into the plugin too, and just added with code rather than dynamically loaded using the normal camel provider module mechanism.  But then you wouldn't be able to access groupwise mail without evolution running (again, which you can't anyway).

I don't know the plans for that code, otherwise I guess I could just do this split on the branch.  Should I just look at this anyway Siva?

On Tue, 2004-11-16 at 21:38 -0500, JP Rosevear wrote:
> On Wed, 2004-11-17 at 09:15 +0800, Not Zed wrote:
> > 
> > On Tue, 2004-11-16 at 11:40 -0500, JP Rosevear wrote: 
> > > On Tue, 2004-11-16 at 22:53 +0800, Not Zed wrote:
> > > > 
> > > > Ok, and I had to remove groupwise from the camel build.  It was
> > > > including a LOT of crap it has no business including.  This needs to
> > > > be fixed, using plugins and whatnot, and not hacking things up in
> > > > camel to force it to work.
> > > 
> > > Do you have a list of specifics or a list of restrictions for camel
> > > requirements on this?  I think we might have to make it temporarily
> > > fugly until the new camel groupwise provider is finished in a couple of
> > > weeks (uses soap instead of imap grossness).  I'm guessing the real
> > > nastiness is the configuration goo that could now be eplugins?
> > 
> > Well it uses a huge pile of crap that doesn't belong in camel.  Stuff
> > based on gobject, e-account/e-account-list, gconf.  Some stuff from
> > evolution's tree, like e-passwords, and e-error (which would require,
> > at the very least libedataserverui dependencies which is totally
> > unacceptable).
> > 
> > Worse, stuff from eds/servers/ which must be built after camel anyway.
>
> I believe this is all configuration stuff, so it could probably end up
> in an eplugin.
>
> Siva, is this doable in a short time frame?  Partha, can you be aware of
> this for the soap backend?
>
> -JP

--

Michael Zucchi <notzed ximian com> "Free Software, putting the Free back in Free Market." Novell's Evolution and Free Software Developer