[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 09:24
Subject: Re: [Mono-list] Mail API


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

    Ah, I was off to my home town (city) for a day.
    I think it's a better idea. I will add something of the sort -
AddAttribute(string name, string value) / AddParameter(...).
    So, let me redefine Header class as follows:

public class Header
{
    public string Name { get; }
    public string Value { get; }

    public string this[string parameter] { get; set; }    // return value
corresponding to the parameter. null if it does not exist.

    public string ToString();    // return full header with all parameters.

    public Header(string name, string value);
    public Header(string[] nameParams, string[] values);    // nameParams[0] and
values[0] = Name and Value. All others correspond to parameters and their
values.
}

    All the methods / properties are overridable. I think this 'd be a better
structure than simply Name / Value.

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

    It will take a lot of time before I understand the basic architecuture of
Evolution. Just got the code from the anonymous-cvs. Though I've heard a lot
about the "beauty" of the code and arch of evolution, but I'll have to get used
to it. It will take at least next weekend - exams coming in. :((

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

    That's what I said... I'll make it MultiPart - making it self explanatory
(?)

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

    I will take care of this in my architecture. Why put extra burden.

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

    Right now I'm checkout-ing the gmime from the cvs. Will see it.

:
: Again, no problem. I'm just glad I could provide some useful input to
: you.
:
: Good luck, and may the source be with you ;-)

    Thanks. I am pretty confident that the source is with me and shall continue
to be with me. ;-)


Cheers,
Gaurav Vaish
----------------------------

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