[Mono-list] none-standardized classes and Mail API

[Miguel de Icaza]

> My guess is that you have decided that whether or not a change to
> the classes occurs trough ECMA or directly from MS is irrelevant.

That is pretty much acurrate.  

> If a change occurs the classes have to be
> modified anyway and furthermore it will not be suitable for MS to change the
> classes too often. 

Exactly.  The changes they make will impact their customers and
themselves.  Historically Microsoft has also been *extremely* good at
keeping backwards binary compatibility.

> It is more likely that functionality will be added, which
> can be just as bad. Have to keep track on which version of .NET Mono
> conforms to.

That should not be hard.  .NET provides excellent ways of building
tools that could actually track this kind of thing. 

> With that said, I would like to contribute to the Mono project, and have set
> my eyes on a mail api. At http://www.go-mono.com/ideas.html the idea is to
> base a mail api on JavaMail or Camel. But, what about System.Web.Mail that
> comes with .NET? I know the classes in the namespace has limited
> functionality compared to JavaMail (don't know Camel), only smtp support,
> and the namespace is not part of the standardization. But wouldn't a
> implementation of the namespace still be useful for the Mono project (e.g.
> my earlier remarks on standardization)? Furthermore a later implementation
> of a more extensive mail api could use the functionality of System.Web.Mail
> namespace if applicable. How do you see it?

Camel is basically an evolution of JavaMail.  The difference is that
Camel is implemented in C with objects (CamelObject) so it is not
straight-forward to understand for those not used to do OO programming
in C.

Camel on the other hand begun as a JavaMail implementaiton, but many
errors and problems were corrected in the meantime that would allow
the implementation of a large mail and modern client (the Evolution
program).

So you might want to start using the interfaces from Camel to build
the mail interfaces you are thinking of and you could translate from C
to C# the actual code.  

That being said, you can then use Camel to implement the Mail
interfaces in .NET.  

Then, we might as a team submit those classes to ECMA for
standarization as well.  Just like Microsoft submitted some of their
classes, we might submit ours.

Miguel.