[OTR-dev] Last-minute change to libotr 4 API

[Ian Goldberg]

On Mon, Aug 27, 2012 at 11:24:24AM -0400, David Goulet wrote:
> Hi everyone,
> 
> I guess I'm a bit late to the discussion but still, I would like to
> clarify things :). I'm pretty new to libotr thus I might be wrong so
> please don't hesitate to correct me.
> 
> As far as I can see in the code base of libotr, there is no poll
> mechanism to receive messages such as a blocking call that returns
> once a message is available (received). However, I see below the
> "otrl_message_poll()" call that I can't find in the git tree so is
> this a new way of handling messages in the 4.0 version ?

That's because I was describing a (then as of yet unimplemented)
proposal.  It's now implemented and pushed to git.  (See my next
message.)

To be clear, otrl_message_poll() does *not* block.  As you say, it would
be bad if libotr blocked.  otrl_message_poll is the function the client
needs to call every so often to see if any timed tasks need doing.  The
client can either just call it every so often, or use the new
timer_control callback to allow libotr to tell the client when to turn
on and off the timer, as well as the timer interval.

> If yes, it would make much senses to me that the library handles this
> timer control call since the lib itself is the one managing the
> communication sockets and knows when the key(s) should be wiped out
> according to a default or user defined timer value.

Actually, libotr does *not* manage the communication sockets.  libotr
doesn't know or care how the encrypted messages get from point A to
point B.  The client application will take the messages produced by
libotr and send them in its usual IM way.

> If there is no such poll mechanism, the user handles the incoming
> packets and than process them with "otrl_message_receiving" for
> instance well calling a possibly blocking function is tricky (on the
> client side). Either the client, using libotr, is doing multi
> threading so the apps don't stall or this call just makes the IM
> client freeze for the timer period... which to me does not seems like
> a good idea...

Right.  No blocking calls to libotr.

Thanks,

   - Ian