[Twisted-Python] twisted.news cleanups and tests

[Jp Calderone]

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 : http://twistedmatrix.com/pipermail/twisted-python/attachments/20030413/44967b1a/attachment.pgp