Justin wrote: > I think that putting all the functionality of logging into > a server, > retreiving messages and folders, and turning that data into XML is a > little too much for a Source. If you have to pass parameters to the > generator to specify servers and passwords, etc.. then why > not just make > a MailGenerator?
My plan is to put the login, retrieval of mail, etc into the Source, and the XML conversion in an XMLizer. So these two functions will be split. As far as passing passwords etc goes, I think Vadim is right that this should all be passed to the Source in a URL string. I don't see any big problems there. I don't think that a Generator should be responsible for dealing with mail servers, because I also want to be able to retrieve rfc822 messages from file systems or web servers, not just POP, IMAP, etc. That's why I think the XML conversion should be UNDERNEATH the Generator layer (as an XMLizer or as an XMLizable Source). >Most mail > systems won't > make a new connection to the server to retrieve each > individual message. > They usually download them all at once into a local store. Will the > source be responsible for this? If you're just concerned with viewing I don't think the Source should do this: storing messages is what a mail server (or any JavaMail "provider") is for after all. I don't want to write a mail server. ;-) > messages and don't want to store them, then you might want to > keep the > connection open so you don't have to reconnect for each > message. In this > case you'd want to store the JavaMail connection in the > session, and I'm > not aware the a source has access to the session. You're right - keeping a cache of connections is important (though not such an issue if the mail server is local) - but I'm still thinking this can be done with a Source. I'm still not entirely clear about the Source's relationship with the rest of Cocoon (including the session), but in any case, it seems to me that a Source can keep a cache of open Connections itself if necessary - it doesn't really have to be stored in the Session. > Who knows, maybe this is a better job for an action or > flowscript in > conjunction with a MailSource, but I don't think a source > should do it > all. Can you elaborate on how that would work, Justin? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
