Re: [Evolution-hackers] camel eds work progress

[Sivaiah Nallagatla <snallagatla novell com>]

On Wed, 2004-11-17 at 11:45 +0800, Not Zed wrote:
> 
> 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.

I am working on making it a plugin. when does e_plugin_lib_enable get
invoked for a plguin? When it is invoked for first time ? I just tested
this approach by   adding a dummy element  to receving options page in
the druid using e-plguin and instantiated camel gw listner in
e_pluin_lib_enable method of that plguin. From my debugging i found
e_plugin_lib_enable gets called for first time only when i run account
setup wizard. camel gw listner has to be created earlier than that as it
has to listen to events like account removal etc (so that it can cleanup
e-sources if it is a gw account)  which user can do without running
account setup wizard even one time.
Any ideas how on how to make sure lisetner gets created during evo
startup or when groupwise provider is loaded ? 

Siva

> 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 )
> 
> 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