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

[Jonas Wielicki]

On 26.08.2012 15:46, Ian Goldberg wrote:
> On Sat, Aug 25, 2012 at 09:03:56PM -0700, Howard Chu wrote:
>> Since there are no other uses for this yet, it might be better to make this a
>> oneshot function. And change the signature of otrl_poll() to also return a
>> polltime. If it returns 0, then no further polling is desired, otherwise the
>> return value is the interval till the next desired poll.
> 
> I thought of that, but it doesn't quite work.  Or rather, otrl_poll
> could *never* return 0, since a new OTR conversation may start at some
> later time, and would need to be scheduled to be cleaned.  You'd have to
> have *every* otrl_* call by the application have the ability to create
> and destroy timers.  So another way to do it would be to have new
> callback functions in OtrlMessageUiOps to create and destroy timers.
> But that also seems ugly to me, and requires more infrastructure from
> the calling app than just "call this function every so often".
> 

Difficult situation. I don't know the OTR API well and am just reading
here passively for most of the time, but I have some suggestion:

(1) If your API supports something like errno() or return codes which
indicate error states, you could specifiy an error code for “everything
went well, _but_ we have a new timer, use otrl_polltime to ask for when
to poll next”. This would make applications which do proper error
checking fail if they miss a timer creation (which may be a good thing).

- or -

(2) You could specify a set of otrl_* calls after which the application
has to call otrl_polltime to ask for the next time it has to poll.

Both would probably require some internal timer scheduling in libotr to
see which timer is next to expire and so on...

-- Jonas