csmail-announce Mailing List for CS Mail API
Status: Pre-Alpha
Brought to you by:
mastergaurav
Menu
▾
▴
csmail-announce — Announcement Mailing List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
|---|
|
From: <csm...@li...> - 2002-09-10 06:02:05
|
Hello, Version 1.0-pre-alpha was released today. It may be downloaded from http://sourceforge.net/project/showfiles.php?group_id=56024&release_id=109857 The release notes follow the signature. Don't forget to read the "Warnings" section. ;-) Website: http://csmail.sourceforge.net Happy hacking, Gaurav Vaish ---------- -------------------------------- Version 1.0-pre-alpha --------------------- * A total of 68 objects being compiled. * Over 6400 lines of code. * Major work in Service (Store and Transport), Folder, Message done. * Mime support underway. MimeBodyPart, MimeMultipart, MimeMessage stubbed. * Header/List, IAddress/List and its implementers done. * All major delegates done. **WARNING** - All code is without any test. Use them at your own risk. - Several methods will throw "NotImplementedException". Contributors to this release: - Idea and API Development: => Gaurav Vaish => Ajay Dwivedi => Jeffery Stedfast - Coding stuff: => Gaurav Vaish -------------------------------- ___________________________________________________ Communicate with others using Lycos Mail for FREE! http://mail.lycos.com |
|
From: <csm...@li...> - 2002-09-05 06:26:08
|
Hello,
Finally some news from my side.
I have been making good progress recently in the CSMail-API and have finally published some documentation for it. The documentation is currently available in two formats:
* Online viewable html files. Jump directly to http://csmail.sf.net/docs/0HELP_INDEX
* Download the (gzipped) compiled html file from http://csmail.sf.net/docs/0HELP_CHM
To have a look at the recent progress, go directly to the homepage at http://csmail.sf.net
Special thanks to Jeffery and Ajay for making this dream reach this stage.
Happy hacking,
master Gaurav
http://csmail.sf.net
----------------------------
Hello,
Finally some news from my side.
I have been making good progress recently in the CSMail-API and have
finally published some documentation for it. The documentation is currently
available in two formats:
* Online viewable html files. Jump directly to
http://csmail.sf.net/docs/0HELP_INDEX
* Download the (gzipped) compiled html file from
http://csmail.sf.net/docs/0HELP_CHM
To have a look at the recent progress, go directly to the homepage at
http://csmail.sf.net
Special thanks to Jeffery and Ajay for making this dream reach this
stage.
Happy hacking,
master Gaurav
http://csmail.sf.net
----------------------------
___________________________________________________
Communicate with others using Lycos Mail for FREE!
http://mail.lycos.com
|
|
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
|
|
From: Jeffrey S. <fe...@xi...> - 2002-07-03 03:26:52
|
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
|
|
From: Gaurav V. <chi...@ly...> - 2002-06-28 14:19:49
|
Testing the list. Gaurav http://csmail.sf.net ____________________________________________________________ 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/ |
|
From: Gaurav V. <chi...@ly...> - 2002-06-28 14:16:11
|
Testing the list. Gaurav http://csmail.sf.net ____________________________________________________________ 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/ |
