Re: [Evolution-hackers] camel->split in? eds or not

[Sarfraaz Ahmed <asarfraaz novell com>]

Hi,

Yes, i think it would be more meaningful to split out camel from evolution [ since evo is more of a shell anyway ]. The points listed down below for having camel as a separate entity definately out-weigh the reasons for it to be part of e-d-s. Moreover, if e-d-s moves to the mode of having pluggable components [ loaded on demand ], camel could then easily provide that interface and e-d-s could still use it. Any third party utility [ nautilus, browser or even exchange in the current form ] could benefit from a separate camel library, since they would not have to link to e-d-s or evolution.

On Tue, 2004-08-24 at 20:07 +0800, Not Zed wrote:

This is a mail i sent internally before, JP asked me to bounce it out, others might have contributions to make here.


There are some compelling reasons for putting camel in eds, but also several for not doing it.

in:

• Camel depends on some minor things in e-util.  E-util will almost certainly have to end up as part of e-d-s so that you can build consistent ui's to access e-d-s data outside of evolution, for account managment etc.  Most probably eplugin will end up there.  etc.  e_iconv would go into e-util if gal is dispanded (if g* still doesn't provide enough functionality).  If e-util is there, camel could also be there.
• Some things in e-d-s need to talk mime and/or need to talk mail, so they should presumably use camel for that, even if they need to be redirected through some corba object.
• Fewer packages to maintain.

out:

• Camel only depends on minor things in e-util.  They could easily be duplicated in libcamel.
• If some things in e-d-s need to talk camel, they can just link to it, since it is separate from evolution.
• A stand-alone camel would probably gain more of a life of its own (even the glib dependency could be dropped with moderate effort) and probably advance faster than one tied to e-d-s.
• Apart from evolution using camel, there isn't any material dependency between the two, it was always designed to be a re-usable mail api.  There is little reason to tie release versions together.

I'm probably leaning toward the out mode.  Any extra community involvement would probably be worth the little extra one-time effort to split it out and the on-going release engineering effort.

--

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

            Cheers
                                        -- Sarfraaz Ahmed <asarfraaz novell com>