[Mono-list] System.Web.Mail Enumerations

[Lawrence Pit]

> 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