On Sun, Apr 13, 2003 at 05:53:46PM +1000, Tim Allen wrote: > > On Sunday, Apr 13, 2003, at 16:16 Australia/Sydney, Glyph Lefkowitz > wrote: > > <snip> > > >twisted.im also needs to be refactored, in order to make its API more > >coherent and easier to register observers of. However, it remains > >unclear whether this kind of functionality actually deserves a > >separate package (that .words will use) or whether it will go into > >.words directly. Moshe has me mostly convinced that it should remain > >an independant package, since real-time-client code is going to look > >significantly different to abstract-message-processing-and-forwarding > >code. > > > >Thoughts? > > I'll be watching this with interest. I'm not going to say it's > impossible or crazy, but I'd like to see how all the inherent > difficulties in making a "generic messagey thing" are overcome. > > From the top of my head: > - IMAP and NNTP have a bunch of folders, POP3 has just one. This is easy, POP3's single folder is IMAP4's "INBOX", and NNTP lives in an entirely different namespace from regular IMAP4 folders. A related point: what isn't clear to me is how to handle the difference between the practically required download-all-messages behavior of POP3, and the complete opposite of IMAP4 and NNTP. > - IMAP lets you create folders and move messages about, NNTP doesn't. IMAP is allowed to reject these operations, so NNTP and POP3 could just have this error behavior in all cases. > - Instant messaging apps have no folders, but you could no doubt > synthesise an 'inbox'. Some IM systems let you have 'categories' of > buddies, which you might present as message folders. However, then IM > has the restriction that a given folder can only contain messages from > one recipient, which is not the case with IMAP or NNTP. Hmm. No ideas from me here, yet. > - POP3 and NNTP need to be polled for new messages, IM protocols alert > you when a new message comes in. I'm not sure which way IMAP goes. This is a kinda neat coincidence. IMAP4 does both. So we need both behaviors, but POP3/NNTP will only use polling and IM will only use notification. > - Email and usenet messages generally have a variety of interesting > and useful headers that end-user applications are going to want to look > at, IM messages do not. I'm not sure what the right answer is here. One solution might be to add headers to IM messages when exposing them through this API. The information for most of the common ones is available: From, Sender, Reply-To, To, Date are obvious, CC and BCC are probably mostly empty (but ICQ used to support multi-person chat, I don't know of any other protocols do, or if ICQ still does); Subject is tough, and Message-ID I guess we'd generate ourself. Those are all the official "envelope" headers that are required to exist, Subject being the only one that we really don't have information about - perhaps giving users a way to tag exchanges with some value, or just leaving it empty? OTOH, it makes sense to view IM messages in groups, not one at a time. I don't see how you could coherently add headers to more than one IM message. > - IMAP and IM are stateful protocols, POP3 is not. I'm not sure about > NNTP. NNTP isn't, unless you go into pipeline mode (which Twisted doesn't support [well?]). Can you go more into why this might be a problem? I think the protocol code should handle any issues raised by this, and present a unified front to the messaging API. > - Email and usenet messages have message-threading, IM does not. I think you could do some neat stuff with temporal analysis and trainable neural networks, but I've got exactly zero practical experience with either of these techniques, so I won't say this isn't a potential problem :) Some problems I foresee: - With email, you should always [according to standards documents, anyway] have a pretty good idea of what kind of data you're being handed. Content-Type and other MIME headers make it easy enough to decypher what someone just sent you, but afaik, no IM protocols that support file transfer deal with this. What's the correct way to handle a file with no meta data? - PGP; we can verify signatures, but security conscious users will want this done client-side - that means preserving the exact structure of the message somehow and then sending it on to them. This doesn't play nicely with the idea of being able to receive one kind of message and send it off as another kind. Jp -- Somewhere, something incredible is waiting to be known. -- Carl Sagan -- up 24 days, 15:01, 1 user, load average: 0.99, 0.90, 0.85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url :