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?
--
|
<<attachment: zed-48.small.jpg>>
