[Mono-list] Mail API

[Gaurav Vaish]

----- 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.

:
: 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.

:
: 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.

: 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.

    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?

:
: 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.

:
: 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.

:
: 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.

: 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.


Cheers,
Gaurav Vaish
http://mastergaurav.virtualave.net
http://calendar.yahoo.com/mastergaurav
---------------------------------

: Jeff