[Mono-list] Mail API

[Jeffrey Stedfast]

Hi Gaurav,

I took a look at the interfaces and have a few comments.

I think you're missing some interfaces for Content-Disposition.
Inline/Attachment is only a part of what a Content-Disposition header
can contain. Often times it also contains some parameters such as
'filename'. When implementing parameters, you'll want to read rfc2184
and/or rfc2231 which describe how to encode/decode parameters.

The same pretty much goes for Content-Type. There needs to be a way to
set parameters and get parameters.

I'm also not convinced that EncodedContent and DecodedData should return
strings. Be aware that emails are not bound by any size limit and thus
we must be careful to not completely swamp the system when getting the
content. I suggest a stream interface for being able to incrementally
read the data.

For class part, you will need a setContent. You may also want a
Constructor that can take a raw mime stream to construct the Part from.

I'm not sure where you are going with the PartList class. You should
just be able to have a simple linked list within each Part. Btw, it may
be beneficial to have a Multipart class that inherits from base class
Part which contains a PartList. as well as interfaces for a Preamble as
well as a Postamble.

At this point, you won't need a class Body. Class message can just
contain a generic Part object (either a Multipart or a Part).

class Message should probably also inherit from class Part since a
message doesn't differ much from a normal Mime Part. This also will more
easily allow you to have multipart/rfc822 message parts as subparts of
Multiparts.

Not sure what class MimeEncoding is?

I'm guessing that class TextPlainEncoding and class
QuotedPrintableEncoding are for encoding/decoding data? If this is the
case, I assume that TextPlainEncoding will handle 7bit and 8bit? You
will also need a Base64Encoding class as well as a BinaryEncoding class.
You may even want to have a UuEncoding class that handles
Content-Transfer-Encoding: x-uuencode.

If you haven't already started implementing anything, I suggest you look
at the Camel interfaces (and maybe GMime as well?). I can tell you from
experience that you will need all of the interfaces that something like
Camel provides for a really good mail library. You may even want to
extend the Camel interfaces some.

Jeff

On Sun, 2002-01-27 at 00:32, Gaurav Vaish wrote:
> Hello,
>     Recently, I'd been busy making an API for Mail services / providers for
> dotNet platform, similar to what JavaMail is for.
> 
>     Till now, I've done some work for the API related to Headers, Part, Body,
> Message, EMailAdress(List) and InternetAddress(List). I'd appreciate critical
> comments on the API, for the so far implemented as well as the architecture and
> to be designed part.
>     I've put up a small discussion at:
>         http://www.geocrawler.com/lists/3/SourceForge/17612/0/7570314/
> 
>     I'd soon be coming up for the Transfer and Store part which will leave me to
> do with classes like / concerning:
>     * Date (esp to deal with various date formats)
>     * MailingList (to deal with Mailing-List, List-Subscribe, List-Unsubscribe,
> Delivered-To etc)
>     * Received (to deal with Received headers, I am not sure whether to separate
> it or not)
> 
>     * TextPlainEncoding
>     * QuotedPrintableEncoding
>     * MimeEncoding
> 
>     * Events and Delegates (specific to folders, transfer and message)
>     * Utils (separate namespace, comprising of mainly searching from various
> parts, special headers [date, received, address etc] of a message)
>     * Exceptions (list of exceptions)
> 
> 
> 
> Cheers,
> Gaurav Vaish
> http://mastergaurav.virtualave.net
> http://calendar.yahoo.com/mastergaurav
> ---------------------------------
> 
> ----
> 

-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj@ximian.com  - www.ximian.com