Re: [Evolution-hackers] EDestination and CamelInternetAddress

[Not Zed <notzed ximian com>]

If we separate camel out it wont be an issue, I guess, since presumably it'll be in eds or eds will end up depending on it - but that depends on if we move it.  I suppose that needs to be sorted out 'real soon now'.  Just dropping the whole lot into e-d-s would be trivial (as much as it would be nice to have standalone), since we'd probably move most its dependencies from e-util or gal to there at the same time.

Without that, its a reasonably fair chunk of code, which would be better not to be copied (and probably best not to be cut-down - anything in it is there for a reason), if it could be avoided.  It also draws in a bunch of other utilities, like the e_iconv() stuff, which is in gal(!) at the moment, which can't really be avoided.  To make it standalone you're probably looking at grabbing at least 3-500 lines of code, and thats just the stuff in camel-mime-utils that does the work, not the stuff in cia (which isn't needed).

But, well, also, ESelectNames should die and be replaced with something which works and has a nicer interface anyway (api and ui).

On Wed, 2004-10-20 at 19:03 -0500, Hans Petter Jansson wrote:
> In order to move ESelectNames into e-d-s, I also need to move
> EDestination. This is a problem because EDestination depends on
> CamelInternetAddress, and Camel is still in evolution.
>
> A comment in e-destination.c mentions that Jeff was writing a stripped
> down version of CamelInternetAddress for EDestination use. What happened
> with that? Is there a better solution?

--

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