[Mono-list] CS-Mail-API

[Gaurav Vaish]

Hello,

 I may not be able to respond to all of your queries right now, but will try to satisfy you at my best. Also, quite a few people responded to my mail and to the replies to my mail. I haven't gone through them and may be reiterating a few thins.

 I may answer all replies to my mail, I gotta leave to other city for my job tomorrow ... gotta do the packing business today ;)

 Regarding the "display" format... I am in way of making the xsl for this, but I'm novice in that.. so, it's taking time.

 InternetAddress.. a simple URL / URI.
 MessageFlags... The enum is marked with attributed "Flags". It IS inface flag, can be ORed.
  FolderType... I already have "HoldsFolders" or something like in the class "Folder". I am sorry, if I missed it during documentation.

  ProviderType: Thanks. I will take care of it.

  RecipientType: Ho. Ho! I'll do that correction.
  ctor = Constructor. You are right.

  Class Folder, Property: "Message[] Messages". Hmmm... You may be right. Okay, for the time being I will put it off. May be put it later on... hmm, this property may be available if the total size of msgs is small ... say about 10-20, but not when there are over 100 msgs. ;-) Not much sure on it right now.


  Thanks once again for all replies.


Cheers,
master Gaurav
 
--

On 02 Jul 2002 23:21:45 -040  
 Jeffrey Stedfast wrote:
>Hey,
>
>Sorry I didn't respond sooner.
>
>First, is there a tool or something I can use to "display" this other
>than a text editor? I'm just not used to reading APIs in XML format...
>:-)
>
>Okay, now for some comments...
>
>	<enum name="AddressType">
>		<member name="EmailAddress"/>
>		<member name="InternetAddress"/>
>		<member name="NewsAddress"/>
>	</enum>
>
>What's an InternetAddress? Anyways, that's not my biggest concern -
>which is that the classes don't seem to address addresses like:
>
>MONO: miguel@ximian.com, mono-list@ximian.com;
>
>These days you rarely ever see this, but at my last job I came accross
>this quite a lot.
>
>	<enum name="MessageFlags">
>		<member name="None"/>
>		<member name="Seen"/>
>		<member name="Answered"/>
>		<member name="Flagged"/>
>		<member name="Deleted"/>
>		<member name="Draft"/>
>		<member name="Recent"/>
>		<member name="UserDefined"/>
>	</enum>
>
>This shouldn't be an enum since you can theoretically have more than a
>single flag marked. For example, a message could be Seen and Answered.
>We use a bit field in Camel to handle this.
>
>	<enum name="FolderType">
>		<member name="Folders"/>
>		<member name="Message"/>
>		<member name="Both"/>
>	</enum>
>
>This might be better as a bitfield too? It might be nicer if the names
>were something more like CAN_HOLD_FOLDERS and CAN_HOLD_MESSAGES (I'm
>partial to caps for enums but my point here is actually the clarity of
>what the value means - myFolder.type == Folders just doesn't convey the
>meaning the same way myFolder.type == CanHoldFolders).
>
>The reason I suggest a bitfield for this is that it makes it easier to
>do something like:
>
>if (myFolder.type & CAN_HOLD_FOLDERS) {
>   scan_for_subfolders ();
>}
>
>sure, you can do it by doing:
>
>if (myFolder.type == CAN_HOLD_FOLDERS || myFolder.type == CAN_HOLD_BOTH)
>but it's more typing.
>
>	<enum name="MessageSortStyle">
>		<member name="Default"/>
>		<member name="From"/>
>		<member name="Size"/>
>		<member name="Date"/>
>		<member name="Subject"/>
>	</enum>
>
>there should probably be a way of extending this? In Evolution, we have
>a lot more ways of sorting than just these (as do many mail clients).
>Actually I'm not convinced that csMail should even worry about sorting.
>This can be done at a higher level.
>
>Same for FolderSortStyle.
>
>	<enum name="ProviderType">
>		<member name="Store"/>
>		<member name="Transport"/>
>	</enum>
>
>yet another bitfield probably? Example: NNTP is both a provider and a transport.
>
>	<enum name="ReciepientType">
>
>type-o :-)
>
>In class ContentType what is ctor? Oh, constructor?
>Just smack me :-)
>
>Is ContentType::Equals() for matching exactly? In Evolution, we do:
>
>header_content_type_is (content_type, "text", "*")
>
>It doesn't use regex or anything complex like that, the rule is that if
>the string is "*" then it's a wildcard else it's not. This is very
>useful when traversing MIME parts looking for a text part for example
>:-)
>
>In class EMailAddress, why do we care about 'host'? I can't think of a
>reason why you wouldn't want to just refer to the entire addr-spec. I
>guess it's no big deal though.
>
>class EMailAddressList:
>
>A good convenience function to have here would be to have a ToString
>method that gave you the encoded address and one that gave you the
>non-encoded (display version?) address.
>
>Also, it seems that there is no way to get the entire EMailAddressList
>as a single string? This would also be useful.
>
>class Folder:
>
><property name="Messages" type="Message[]" allow="get;"/>
>
>this is gonna require a ton of memory for a folder of any considerable
>size. I suggest having a method to instead just get a summary of
>messages. Imagine:
>
>class MessageInfo {
>   string from;
>   string to;
>   string cc;
>   string bcc;  /* is this even really needed?? */
>   string subject;
>   string message_id;
>   string references;  /* needed for proper threading */
>   DateType sent_date; /* date in Date: header */
>   DateType rcvd_date; /* date received, if different from sent_date */
>   Uint32 flags;       /* bitfield of Seen/Deleted/etc */
>
>   ...
>};
>
>This will require much much less memory and would also be considerably
>faster to "load" (especially in the IMAP case) since it will require so
>much less I/O.
>
>Oh, my bad... farther down you have a GetMessages() method that only
>gets specific messages that you request. However, you still have no way
>to get a summary like I suggested above for constructing a message-list
>in a client application so I guess what I said above still applies.
>
>	<class name="FolderAddress">
>
>This class looks exactly the same as URLName, so this should probably be
>scrapped.
>
><class name="Message">
>
>Okay... most of my comments for this class are uncertain... the ideas
>are just the way I'm used to doing things and not necessarily "wrong".
>
>For example, I don't think we really need Message::Flags (which also
>means we won't need Message::IsSet()). But to get rid of the IsSet()
>method, we'd need a method on the folder to get this info. You should
>probably have a method for getting the MessageInfo based on a message or
>a UID or an index.
>
>A message's flags are really just metadata and not really part of the
>message at all. Or at least that's my paradign.
>
>Message::IsExpunged() sorta follows the same idea...why do we need this?
>If we have an instance of the message, do we really care? I dunno,
>perhaps it could be useful.
>
><method name="SaveChanges" type="abstract"/>
>
>This method doesn't really make sense for spools, of course SaveChanges
>could be implemented to delete the original message and append the new
>form of the message to the end of the spool?
>
>I don't think the message needs to reference the folder either, however
>doing so could simplify things.
>
>Anyways, that's all I can think of at the moment.
>
>Jeff
>
>On Thu, 2002-06-27 at 08:55, Gaurav Vaish wrote:
>> Hello everybody,
>>  I have now released the first version (not draft) of the API.
>> 
>>  I would like some comments on it, especially from geeks of evolution/camel (if here) and ppl like AjayD.
>>  ;-)
>> 
>>  I am also attaching a copy of the same here.
>> 
>> 
>> Cheers,
>> Gaurav Vaish
>> 
>> 
>> ____________________________________________________________
>> Win a first-class trip to New Orleans and vacation Elvis Style!.
>> Enter NOW!
>> http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes/
>-- 
>Jeffrey Stedfast
>Evolution Hacker - Ximian, Inc.
>fejj@ximian.com  - www.ximian.com
>
>


_____________________________________________________
Supercharge your e-mail with a 25MB Inbox, POP3 Access, No Ads
and NoTaglines --> LYCOS MAIL PLUS.
http://www.mail.lycos.com/brandPage.shtml?pageId=plus