-----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 [email protected] > 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----- _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
