Re: [Evolution-hackers] Evolution Future Roadmap
- From: Peter Colijn <pcolijn gmail com>
- To: JP Rosevear <jpr novell com>
- Cc: evolution-hackers ximian com
- Subject: Re: [Evolution-hackers] Evolution Future Roadmap
- Date: Fri, 23 Jul 2004 16:06:48 -0400
Hi,
On Wed, 21 Jul 2004 12:43:15 -0400, JP Rosevear <jpr novell com> wrote:
> This plan is to to cover 3 versions after 2.0, coinciding with approximately 6 month releases cycles of GNOME, this is mostly core stuff and not absolute (for instance we'd put in other backends for opengroupware, exchange it, etc if they became available). We want to list specific functional goals that are largish in nature. A lot of smaller features will just end up as EPlugins.
I'm one of the main developers of ExchangeIt. William Lachance and I
discussed the possibility of including the ExchangeIt connector as
part of e-d-s for 2.2 or 2.4 with Dan Wensley at GUADEC. What would
you need from us to make that happen?
> 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?
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?
> 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.
> 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?
> Evolution 2.4 (Autumn 2005)
> camel plugins
How do these relate/compare to the EPlugin stuff?
> 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.
As for William McCann's comments that send/receive doesn't make sense
for anything but mail, I have to disagree. With collaboration software
that is sync-based, like ExchangeIt, you reall do "send/receive"
calendar items, contacts, and tasks when you sync, so it makes perfect
sense. Ditto for "offline/online" status. In fact the way we have our
connector right now in 1.4 is pretty nice; it's just too bad it had to
be done in such a hacky way.
For the most part, this sounds good! I'm looking forward to it!
Have fun,
Peter
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]