[Mono-list] Mail API

[Jeffrey Stedfast]

On Mon, 2002-01-28 at 21:23, Gaurav Vaish wrote:
> ----- Original Message -----
> From: "Jeffrey Stedfast" <fejj@ximian.com>
> To: "Gaurav Vaish" <gvaish@iitk.ac.in>
> Cc: <mono-list@ximian.com>
> Sent: Tuesday, January 29, 2002 01:24
> Subject: Re: [Mono-list] Mail API
> 
> 
> : Hi Gaurav,
> :
> : I took a look at the interfaces and have a few comments.
> 
>     Thanks for your time and the suggestions.

no problem ;-)

> 
> :
> : 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.
> 
>     Yes, I have already gone through these RFCs. The thing what I wanted to put
> in by the enumerations ContentDisposition and ContentType was the "compulsory"
> parameter. The filename etc parameters are but optional. You may or may not
> have. Also, they cannot be put as enum's. Though, as you suggest, I may as well
> provide interfaces (or better classes) for ContentDisposition, though personally
> I would not like that. A tool should generate the header and add it using Header
> class.

Okay, that would work... It would be nice as a convenience thing to have
interfaces for setting parameters though. This makes it so that only one
place in the code has to worry about doing proper rfc2231 encoding of
parameter values and such. If the mail client has to do the encoding,
you open yourself up for problems.

> 
> :
> : The same pretty much goes for Content-Type. There needs to be a way to
> : set parameters and get parameters.
> 
>     Yes! I can add these methods for the Header class!
> 
> : 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
> 
>     How can I miss this. It *MUST* be a stream, may be a simple StringStream
> would suffice.
> 
> :
> : 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.
> 
>     But I already have the property "Content" that allows both get as well as
> set. A constructor with raw mime-stream can be easily added.

Yea, I know you currently have a set method - I was mostly just
commenting on your comment in the pseudocode.

> 
> : 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.
> 
>     Oh, I just saw, I did not complete the PartList class. It's basically an
> implementation of a collection of Part's, may be, linked list Part or a vector
> (overheads here) or what ever. But I may very well remove this and modify Part
> so as to allow space for linked-list_ing Part.

Actually, I think a vector or a list of parts would be better than a
Part being a linked-list node. It's possible that you may want to put a
Part into multiple Messages/Multiparts/whatever. We do this a lot in
Evolution for example...

> 
>     Basically, what I wanted was to have was Body to contain PartList. You call
> it MultiPart - well, that may be a better name, though I cannot see any other
> difference between the two, or am I missing something?

Okay, I guess I just misunderstood. I think I would personally prefer
"Multipart" rather than "Body" because it is more clear what the
abstraction is (to someone who has read the MIME spec at least). But
that's just a naming convention, it's not really important.

> 
> :
> : 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).
> 
>     Oh yes, I did not missing anything. Multipart = (Part)+ and so is Body. But
> MultiPart, by name, looks closer to 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.
> 
>     Thanks. That really really useful. Removing a lot of burden of lower-order
> classes and putting a good hierarchy in place.

Yep ;-)

This is one mistake I made when I wrote GMime. GMimeMessage should have
inherited from GMimePart, but it didn't so I'm not able to use a
GMimemessage as a GMimePart :-\

> 
> :
> : Not sure what class MimeEncoding is?
> 
>     Damn, it should have been Base64. There's nothing as "MimeEncoding". Silly
> me.

:-)

> 
> :
> : 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
> 
>     I have space for them. I did not list all of the standard / popular encoding
> schemes. TextPlainEncoding will take care of 7bit and 8bit and any other popular
> variant.

Okay, cool. I just wanted to make sure they didn't get overlooked ;)

> 
> :
> : 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
> 
>     Well, I haven't started as yes. I'm in designing_arch phase right now. I've
> recently been trying to go through Camel, though have not looked at very closely
> because of my tight schedule. GMime - that's new to me. Will have a look at it.

GMime is something I wrote up in my bored spare time. It's basically a
simplified Camel MIME implementation.

> 
> : 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.
> 
>     I will be more than willing to do so, but only if I find some time off the
> "new" platform applications. That's quite interesting - starting from scratch
> and building a-top, though building in c/c++ is even more exciting. I love
> implementing c++ structues (class, hierarchy, polymorphism!!) through c
> structures (structs, lists, enums).
> 
>     Thanks once again for your comments. It will definitely help in making the
> API even more promising.

Again, no problem. I'm just glad I could provide some useful input to
you.

Good luck, and may the source be with you ;-)

Jeff

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