Lists Home |
Date Index |
- From: "K.Kawaguchi" <email@example.com>
- To: Michael Rossi <firstname.lastname@example.org>, email@example.com
- Date: Tue, 08 Feb 2000 11:58:16 +0900
> I don't think it's just you. A dedicated system/service could undoubtedly
I'm still wondering if such SMTP/POP3 components are worth implementing.
Firstly, there's a good chance that such components have already made
available by someone else. Secondly, I'm not still sure if it can
receive some supports from other developers.
> think you could meet a large majority of common requirements with an
> adequate specification of how common transport protocols should be used.
Implementing protocol-side code is not difficult, but when it comes to
"adequate interface"... Ummm, it's no easy for one person to do.
My impression is that many existing POP3 components (mainly commercial
ones) are too much protocol-oriented; I mean, they have methods like
connect, login, retrieve, delete, quit, ... I don't want to be bothered
by those POP3 commands.
Since what I want here is not general-purpose component but queue-like
component, the interface could be much simpler.
I don't need multipart mail support, nor decoding to appropriate
character set (XMLparser will do the job).
With these considerations in my mind, the interface should be like this:
--- Oh, I don't know if it's OK to start things like this here. If it's
not, please tell me so.
BSTR Server,PortOrService // connection stuff
BSTR To,From,Subject,... // mail header stuff
IXMLDOMDocument* BodyXML; // get contents as XMLDOM.
void Delete(); // deletes this message from the queue(server)
client code should be as follows:
while( m = POPQueue.Pop() )
// do the processing
if( succeeded )