Re: [Evolution-hackers] Evolution Future Roadmap

[Not Zed <notzed ximian com>]

> >  Evolution 2.2 (Spring 2005) 
> > detaching camel from evolution 
>
> I'm interested in this point. What specifically would this involve?
> Right now with our connector for 1.4 we have a tiny Camel provider;
> it's there so that we get called on a "Send / Receive" operation, and
> all it does is notify our shell component to do a sync, and receive
> progress updates. Really all we wanted was to hook into send/receive
> and have a progress bar; in 2.2 will it no longer be necessary to have
> a Camel provider to do these things?
It just means camel will be distributed as a separate library, exactly how gtkhtml is.  It will make no material difference on its api's or on its use inside evolution-mail, apart from perhaps making its development less flexible and potentially less tightly-coupled (although we've been fairly careful to stick to well defined abstractions).
> Are there any plans in general to make Camel less "special" in
> general? Right now Camel and mail can do much more than the other
> components. Any plans to make Camel part of e-d-s?
What do you mean less special?  Its for email?  About the only think I can think of is that it does 'more' is that it has a single point of run-time extensibility, which the other components don't have.

If you're using camel to 'hook' into evolution even if your product isn't implementing any email functionality there, then thats just a failing of the other components for not providing such hooks.  They can't load anything at runtime, and don't even have the pretty basic run-time generated configuration screens that the mail account editor has.  So the issue is outside of camel or mail.  You could also just do it at a completely different level, i.e. a new toplevel 'component' which has access to things like send/recv and offline state, and is the one extensibility mechanism outside of email.

The new plugin stuff should provide an extension mechanism post 2.0 to handle things like this from any component anyway, see the evolution log on codeblogs.ximian.com.  Once it gels into form and has some documentation around you may wish to provide feedback on any issues it has - although I don't want to make it do everything possible, rather, enough to be actually useful.

> > our own libical implementation based on the vcard parser 
> > attachments to events/tasks 
>
> How are attachments going to be handled? Using a URI in the iCalendar,
> or base64-encoded inline or something? In case of the latter, I assume
> whatever libical implementation there is will be async, or at least
> have an async API, so opening up a calendar item with 100MB powerpoint
> attachment doesn't take forever.
If its like anything else in the calendar, it'll just load it into memory, and make it slow while its at it! :)
> >  EPlugin 
> > hook into any popup menu 
> > hook into main menu's, based on current view and view context. 
> > hook into configuration pages 
> > hook into in-line display of mail content, at the very least for imip and the like. 
>
> Cool.. definitely looking forward to this. Progress bars?
Gtk does progress bars doesn't it?
> >  Evolution 2.4 (Autumn 2005) 
> > camel plugins 
>
> How do these relate/compare to the EPlugin stuff?
They're not really as important since camel already has extensibility for the core function of storing email.

They're also different since they're not based on gobjects, need to be thread safe, etc.
> >  Other 
> > unified account support to share connection information among backend types
>
> Also sounds like a good thing for us, since ExchangeIt doesn't do
> email and this sounds like it'll make it easy for us to auto-configure
> an IMAP account like the GroupWise connector does.
It wont really cover that since I presume email will run on a separate service/server; i mean, we already do that.  Its more for when you have multiple services running through the same service/connection, which we have no mechanism for handling.  Although I guess it will have to cover both cases in effect.

--

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