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

[Mads Pultz]

> From: Jeffrey Stedfast [mailto:fejj@ximian.com]
>
> The way I see it, System.Web.Mail should use the classes that implement
> Camel or JavaMail. No sense in implementing mail twice. The problem with
> your idea of having a later mail implementation use System.Web.Mail is
> that you wouldn't be able to build on it effectively since
> System.Web.Mail wasn't designed to be extensive. It's much easier to
> build a limited class on top of an extensive class, but the opposite
> does not hold true.

I'll have to agree with you on that. Inheritance could be used to extend an
API but I don't think it is appropriate in this case because the base
classes would be too tired to System.Web.Mail.

> From: miguel@ximian.com [mailto:miguel@ximian.com]
>
> ...
>
> 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.
>
> ...

If I understand you correct you would prefer that the Mail API for Mono to
be based on Camel. It makes sense because Ximian already has this mail API
as a project. But how would you go about it? Make wrapper classes in C# that
uses Camel or a 100% C# implementation. Concerning the former how tired is
Camel to the Gnome environment? Concerning a C# implementation how would it
be suitable to reuse the Camel code. A very close relationship by
translating C structs to C# structs, or just use method implementations and
translate to OO in C# (classes and inheritance)? Are there any other
documentation on Camel other than the source?

Concerning JavaMail. Is it likely that the existing JavaMail code (source or
bytecode) will be able to run on top of the CLI platform? There might be
some license issues (most likely), but if not it might be better (or wiser)
to see that the future reveals.

Mads