[otr-dev] Creating a libotr.so ...

[Rüdiger Kuhlmann]

>--[Paul Wouters]--<paul at xelerance.com>

> Of course, to not break gaim-otr, the rewrite of gaim-otr/libotr has to
> happen at the same time, or libotr needs a new version used for this.

Well, it could change behaviour depending on whether certain call-back
functions are NULL or not.

>--[Evan Schoenberg]--<evan.s at dreskin.net>
> On Jun 9, 2007, at 10:45 AM, Rüdiger Kuhlmann wrote:
> >So can we please please make the library stop resending stuff and  
> >leave it
> >up to the application?
> As an application implementor, I most certainly don't want to have to  
> deal with resending.  The current, automatic handling seems very  
> appropriate to me.

I'm not sure what kind of application you're implementing, but any IM
client needs to have some kind of resending mechanism anyway, e.g. to
resend messages once a client-to-client connection is set up.

> >Well, I'm not using cvs - I can't expect people to have dev versions
> >installed for dlopen to grab.
> So in a perfect world, what would you hope to happen in response to  
> your comment here?

Nothing. He asked me whether I had looked at CVS, I answered no and
explained why.

> >I managed Kopete to display me an HTML message complaining about a
> >plain text that visibly contained an OTR offer tag.
> Could you please write the precise steps to reproduce to cause that  
> error to occur? In about 2 years of using OTR I've never seen this.

I've seen it the first time I used it. The steps are simple. With one
client, open an OTR connection (which won't work if the other side
is Kopete and can't see you as Kopete doesn't do fragmentation on its
own, but it suffices if Kopete believes there was one). Exit the client.
Restart the client. (Well, logging in again suffices.) Send an plain
text message. See screen shot: <URL:http://www.micq.org/otr.png>.

> >>--[Evan Schoenberg]--<evan.s at dreskin.net>

> >That would be a start.
> What more would be required to fit the needs you've described?

The functions instrumenting in- and outgoing messages shouldn't
return an error, but a status, which could be:
* message is plain text, no session established
* message is plain text, although session is established
* message is plain text, offer tag was appended
* message (outgoing) must be resend when session is established
* message is encrypted with unverified finger print
* message is encrypted with verified finger print

> > I think that reading all list message before answering would have saved
> > you the time to write this email... My overall complaint is that libotr
> > is so Gaim-specific that it is not really a general purpose library.
> It's not only difficult but often counterproductive to write a  
> library which is generalized far beyond its current use.  I should  
> imagine that patches which make the library more general without  
> breaking current functionality would be happily reviewed.

It isn't generalized enough for even the _current_ usage. And currently
I have the impression that starting from scratch might even be more
successfull, as GAIM centrism seems too strong otherwise.

>--[Scott Ellis]--<mail at scottellis.com.au>
> >Btw, the Miranda plugin has a severe usability problem
> but, fair enough - i'll fix it so you can cut-and-paste.

Thanks. I apologize if my reports have not been accurate as they were only
second hand.

PS. What part of Mail-Followup-To: otr-dev at lists.cypherpunks.ca
do your email clients fail to understand?

-- 
"See, free nations are peaceful nations. Free nations don't attack
 each other. Free nations don't develop weapons of mass destruction."
      - George W. Bush, Milwaukee, Wis., Oct. 3, 2003