[Mono-list] Re: Contributing non .NET libraries

[Greg Pasquariello]

Actually .NETMail is intended to support an entire mail system.  The
messaging and MIME support is already there (though it doesn't yet
support UUEncode encoding).  

Perhaps what I'll do, to avoid the dependency, is deliver the existing
System.Web.Mail classes that talk directly to SMTP.  That way, if you
decide you'd like to utilize .NETMail you can, but are not required to
do so.

---
Greg Pasquariello
gpasq@theoreality.com


> -----Original Message-----
> From: mono-list-admin@ximian.com 
> [mailto:mono-list-admin@ximian.com] On Behalf Of Miguel de Icaza
> Sent: Tuesday, February 12, 2002 5:07 PM
> To: Greg Pasquariello
> Cc: mono-list@ximian.com
> Subject: [Mono-list] Re: Contributing non .NET libraries
> 
> 
> > Over the past few weeks, I've been developing Theoreality 
> .NETMail, a 
> > library of mail functionality for .NET.  It provides full messaging 
> > functionality, SMTP client and server functionality, POP client and 
> > server functionality, working on IMAP, etc., etc.  Future 
> direction is 
> > to integrate with Instant Messenging, NNTP News, Calendaring, etc. 
> > Layered on top are user mail services such as Spam avoidance, rules 
> > processing and the like
> 
> Very nice!  I would like to know more about this.  It seems 
> like this is complementary to the work that Gaurav was 
> proposing.  .NETMail seems to be a transport/delivery 
> mechanism, while Gaurav's is more of a Mime/RFC framework for 
> creating/extracting these messages.
> 
> Is this the case?
> 
> > What I'd like to know is if Mono is interested in getting 
> .NETMail as 
> > part of the Mono .NET framework.  Related to that, currently the 
> > System.Web.Mail classes are self-contained... They handle messaging 
> > and SMTP communications within the library, but they could 
> be easily 
> > modified to utilize .NETMail.
> 
> Sure, I would love to know more about this.  
> 
> If we were to use .NETMail, I can only foresee a problem with 
> adding the dependency in Mono: it would make it harder for 
> people that are trying to compile Mono.  We can find 
> alternatives (for example, we could 
> mirroring the code in one cvs tree to the other).
> 
> As I suggested Gaurav, for any code that is not part of the 
> Microsoft API, we should create extra assemblies.  It is 
> perfectly fine if our assemblies do depend on the extra ones.
> 
> So for example, we will have another extra assembly with the 
> WebServer classes (do not know the exact name ;-) and 
> .NETmail and Gaurav's work. They can all be elements that we 
> use internally.
> 
> If someone wants to use the API directly from their 
> application, they can just use reference them 
> (/r:dotnetmail.dll, /r:webserver), but always working on both 
> Windows and Mono.
> 
> For now, I think that having a standalone system will 
> simplify the deployment in the Mono CVS (until we figure out 
> how you want to publish the code)
> 
> > Anyway, I'm new to mono and not quite sure of the protocol for 
> > contributing.  Is this something anyone would care to have 
> as part of 
> > Mono?
> 
> Check:
> 
	http://www.go-mono.com/ccvs.html

For details on getting your CVS account.

Miguel

_______________________________________________
Mono-list maillist  -  Mono-list@ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list