> I see that at least some of the API is modeled after Camel's API (or at > least the JavaMail API which Camel stole a lot of ideas from).
Erm.. I'd hardly call it an API yet ;) > It would be really nice for the encoders/decoders, for example, to work > more like they do in our (Ximian's) Camel Mail API where they act as a > stream filter, thus allowing incremental encoding/decoding of streams. What you describe is also how Sun has implemented their JavaMail APIs. What I've done so far is nothing much and I'm aware that it should move to stream filters. > I think the SMTP code could also benefit from mimicking Camel's SMTP > implementation which covers most extensions that you would probably care > about including SASL, STARTTLS, ENHANCEDSTATUSCODES, etc. It also > contains a few work-around hacks for broken server implementations that > you may find useful ;-) That would be nice. There's one thing I really miss with JavaMail though (and therefor with Camel too?), and that is that it doesn't act as an SMTP receiver. JavaMail is really only a client side abstraction of mail handling, while I'm (more) interested in a server side abstraction. See e.g. Apache's James. Also, specifically with .Net we have excellent remoting interfaces, and it would be really good to offer an SMTP Channel so you'd be able to send/receive remoting messages via SMTP and POP3. > The following URL provides a cvsweb type of interface to the Camel cvs > repository. > > http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=evolution/camel > > Another advantage of following Camel as closely as possible is that > Camel has proven itself in the Real World. > > I hope you consider looking into Camel as a reference. I will. Greets, Lawrence _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
