[OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals

[Mark Doliner]

On Thu, 23 Feb 2006 22:33:20 -0500 (EST), Etan Reisner wrote
> On Fri, 17 Feb 2006, Evan Schoenberg wrote:
> > (Please reply-to-all, as I'm sending this to both relevant lists)
> >
> > AIM DirectIM can't work within an OTR-encrypted chat; the same is true of any 
> > other gaim plugin-based encryption scheme.
> >
> > 1) User sends message in Gaim
> > 2) Gaim gives plugins an opportunity to modify the message; an encryption 
> > plugin such as gaim-otr encrypts the message if appropriate, returning the 
> > encrypted message
> > 3) Gaim sends the encrypted message to the prpl
> > 4) In the case of oscar within a DirectIM session, the message is normally 
> > post-processed, looking for <IMG> tags, which reference ids from the gaim img 
> > store in the form <img='2'> where gaim_imgstore_get(2) will return the 
> > GaimStoredImage* for the image.  The image's data, size, etc. are inserted 
> > into the message..... but the message is encoded, so such a tag isn't found, 
> > and images can not be sent.
> >
> > A similar situation exists on the receiving side, where the prpl processes 
> > the incoming message, looking for <img> tags to convert to the gaim img store 
> > and their corresponding IDs but sees only the gibberish of an encrypted 
> > message.
> >
> > As I mentioned, this is not specific to the gaim-otr implementation but 
> > rather a result of how the signals are set up.  One solution I've come up 
> > with is giving the prpl a chance to modify the outgoing message before it is 
> > sent to plugins via a signal, and similarly call the prpl for final 
> > post-processing of incoming messages after the first signal is sent when 
> > receiving a message.
> >
> > Thoughts?
> >
> > Cheers,
> > Evan
> > www.adiumx.com
> 
> I only partly understand the issue here, and I have next to know 
> undertanding of the underlying encryption stuff, but couldn't a prpl 
> that needs to do this processing just use the same signals that the 
> encryption plugins use? And use the signal priority stuff to ensure 
> that they come first, to facilitate this we can change the handful 
> of GAIM_PRIORITY defines to be an enum with default levels for 
> PRPL/ENCRYPTION/etc. Would that not solve at least some of the 
> problems? Or is there something I'm missing? Does the prpl 
> processing do funny things to the message that the plugins would 
> have to know about to deal with or something? Would the prpls need 
> to keep track of messages between the signal and the normal 
> mechanism somehow? (Would we need to start tagging messages with per-
> conversation ids to make this work more easily?)
> 
>  	-Etan

It sounds like that would work, and would be cleaner
-Mark