[OTR-dev] Requirements for libotr4

[Ian Goldberg]

On Wed, Jun 18, 2008 at 02:06:06PM +0200, Jonathan Schleifer wrote:
> There's one thing we'd absolutely need for libotr4 to support OTR in
> Gajim again (this is the main reason why we removed the OTR code from it
> completely):
> When calling otrl_message_fragment_and_send, it returns the fragments
> and calls our inject_message method. Our inject_message method calls
> send_message, which returns an ID. This is the ID used by the XMPP
> library for the sent XMPP message stanza. We need this ID for some XEPs
> like for example XEP-0184 (so we can verify our message was received -
> note: XEP-0184 is just chosen as an example here, there are even more
> that require knowing the ID of our sent XMPP message stanza). With the
> way this is handled in libotr3, we just loose that ID and thus can't
> implement some XEPs (thus we removed OTR form Gajim).
> As you already said you're going to remove
> otrl_message_fragment_and_send, I'd suggest that the new API
> includes a way to get the return value of the inject_message
> function (our inject_message function could just return the
> ID from send_message then) so we can get the XMPP message stanza ID.

Isn't that what opdata is for?  inject_message returns void, because we
can't predict what kinds of things you might want to return.  Instead,
it takes as a parameter an arbitrary void* opdata, which you can use
however you want (pass &retval for example).

So your inject_message function could set *(XmppId *)opdata = id and
you would have access to that when the call to otrl_message_sending
completes.

But I thought XMPP didn't need fragmentation, anyway?  If you use a
fragment policy of OTRL_FRAGMENT_SEND_ALL_BUT_FIRST or
OTRL_FRAGMENT_SEND_ALL_BUT_LAST, and there's no fragmentation to be
done, otrl_message_fragment_and_send will just return to you the
(unfragmented) message to be sent, and you can send it yourself.

What do you think?

   - Ian