[csmail-announce] Re: [Mono-list] CS-Mail-API
Status: Pre-Alpha
Brought to you by:
mastergaurav
From: Gaurav V. <gva...@ly...> - 2002-07-04 10:15:23
|
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: mi...@xi..., mon...@xi...; > >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. >fe...@xi... - 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 |