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

[David Goulet]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.

That makes way more sense. Sorry for the confusion, the
"otrl_message_poll" function name misguide me by thinking it was a
poll() mechanism for message events.

David

> 
>> 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 _______________________________________________ OTR-dev
> mailing list OTR-dev at lists.cypherpunks.ca 
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJQO+90AAoJEELoaioR9I029csH/2p9X4I+JU/G9/ycAH/l81Qp
nDLXPoeJ8voFtsFNM+Ifo2eZRw6xuRkpt9cwEehkh2EbhQoVd4k77FOhYgtzkX7q
ZfpmCBMbcQ3fqYqzUL4//lXfN+aY1X+kDd34nBldfiWQjcfmEU7dUZadQIXtMEX9
jTItqxigr2+022+Ct/+0/Br3I7qturm5w/DUDnDBvFQQAp7GDkPi0Hy7ITg0VsSh
pY1fXih1WXu6wJAs7UZaoCmOWJ2zpt2xt9Ul8zPzeYAWmozLpC66vAdFactWG/23
HV2+CCHw6ub0hLpzCPkWQyYUzCtDjRrBUcknCfuvCAJD6Od4S8pXNq6pmbgvs9A=
=IPTp
-----END PGP SIGNATURE-----