Re: [Evolution-hackers] Evolution Future Roadmap

[Peter Colijn <pcolijn gmail com>]

Hi again,
 
> 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).

Ok, that makes sense.

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

Well what I mean by saying that camel is "special" is that it's only
way to get your own account type and get called at send/receive. When
your product doesn't do email, having an "email" account set up for it
doesn't make sense. And having another "sync"-type button only for
your product clutters the UI unecessarily. So basically I'm saying I
wish it weren't necessary to have a camel provider to do these things,
and it seems somewhat inflexible, given that camel is (more or less)
only for mail. And by making camel less "special" in these ways, I
wasn't really suggesting that camel should no longer be doing this
stuff, just that it would be nice if there were other ways to do it
too, and it sounds like there will be, so that's good:

> 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.
 
I do read the evolution log, and saw the posts on EPlugin. I'll make
sure to take a closer look at it. I understand that you don't want it
to become any kind of dumping ground... And yes, Gtk definitely does
do progress bars, but having a separate progress bar isn't as nice
(doesn't feel as "integrated", etc.) as having an evo progress bar.
 
> If its like anything else in the calendar, it'll just load it into memory, and make it
> slow while its at it! :)

Hmm... :) Apparently (this is mostly what we hear from our business
office in Toronto, so it may be exaggerated) a lot of our customers
really like having nice big attachments on calendar items, and they
actually use Outlook as a way to share files this way (however stupid
that sounds, that's what they do).  But if/when attachments on
calendar items and contacts are supported, as long as they can be done
by setting an attachment URI in iCalendar/VCard, I think this will be
fine (I think the iCalendar spec even mentions this as an appropriate
way to do attachments, as well having them bas64-encoded inline).

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

Right, so camel "plugins" will just be what camel providers are now?

Thanks,

Have fun,

Peter