Re: [Evolution-hackers] EDestination and CamelInternetAddress

[gordon <gordon ksoft-e com>]

ya...I dont think its hard..."to seperate Camel out [this week]"

I have a standalone build of Camel, which works ok ,-
o from evo 2.0.1 code [not CVS]
o havent tested with evo itself [ouch, no excuse]
o works ok over pop, local, smtp

So...was planning to finish this nicely and offer a patch [with a couple 
of command line send/recv sample progs] - but likely a few weeks off..


Basically I put together a subset of e-util that Camel needs and
added some small cutnpaste from gal et al.
I changed a minor #include lines in Camel, but no code.

Does someone want to take what I have now and fold back into your CVS etc?

[ Please seriously consider keeping Camel seperate from e-d-s eg.
Then people can use nice messaging library with no big dependencies ]
 
Here is file list for my hacked e-utils [lots of other e-utils cut, as 
they depended on otherstuff, and Camel didnt need them]

e-host-utils.c
e-host-utils.h
e-iconv.c
e-iconv.h
e-memory.c
e-memory.h
e-msgport.c
e-msgport.h
e-path.c
e-path.h
e-sexp.c
e-sexp.h
e-time-utils.c *
e-time-utils.h *
e-trie.c
e-trie.h
filter-rule.h *
iconv-detect.h *
md5-utils.c
md5-utils.h

*indicates hackery

Does any one want my build tree so they can do this??
[I intended to make a decent cvs patch..but wont be able to for a while 
due to other work]

gord.

<rant>
Camel - I like it...Id like to work on stuff like -
- a db [unix odbc] provider/store
- a logging provider/transport
- fully inverted indexes on message text [at e-d-s level] 'like gmail'
- add a bit of glue so you can make messaging 'apps' by just writing sexps
</rant>



Hans Petter Jansson wrote:

> On Thu, 2004-10-21 at 09:18 +0800, Not Zed wrote:
>
>  
>
> > 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.
> >    
>
> Yeah, it needs to be sorted out as soon as possible.
>
>
>  
>
> > 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).
> >    
>
> I'll do that until the Camel situation is resolved, then. Unless it can
> somehow be resolved this week.
>
>
>  
>
> > But, well, also, ESelectNames should die and be replaced with
> > something which works and has a nicer interface anyway (api and ui).
> >    
>
> Well, that's part of what I'm doing. I still need EDestination for it to
> work at all.
>
>