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

[Evan Schoenberg]

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.

>>> * It is impossible to signal back to the library that an injected
>>>   message could not be sent due to size constraints. Thus, the  
>>> library
>>>   does not provide for outgoing fragmentation at all!
>> As Paul said, RSN.
>
> 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?  Ian indicated that this was in progress.

>> If otrl_message_receiving
>> gets an OTR Query message, it will start key negotiation.  If it  
>> gets a
>> plaintext message with the whitespace tag, and your policy is set to
>> reply to whitespace tags, it'll start key negotiation.
>
> 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.

>> --[Evan Schoenberg]--<evan.s at dreskin.net>
>> On Jun 7, 2007, at 6:39 PM, Ian Goldberg wrote:
>>> I agree that the otrl_message_* routines blur the line between  
>>> library
>>> stuff and app stuff.  That's where the English HTML messages all  
>>> live,
>>> for example.  The reason we moved them from gaim-otr to libotr is  
>>> that
>>> we thought they may be useful to other apps.  But I totally agree  
>>> that
>>> some refactoring may be useful there.
>> Optimally, these messages would be available in the library but not
>> in their current form.  It'd be awesome if the library passed back
>> defined error codes which could then, at the application's
>> discretion, either be used to generate its own messages or passed to
>> something like
>> const char *otr_get_error(otr_error errno)
>
> That would be a start.

What more would be required to fit the needs you've described?

> 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.

-Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20070609/d7d4a772/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20070609/d7d4a772/attachment.pgp>