[OTR-dev] Requirements for libotr4
js-otrim at webkeks.org
Wed Jun 18 10:47:37 EDT 2008
Ian Goldberg <ian at cypherpunks.ca> wrote:
> 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).
I must admit that I'm not too familiar with libotr itself as I only used
the pyotr bindings of it (Gajim is written in Python).
So basically, you say I should give a void *opdata to the
otrl_message_fragment_and_send function and modify it in the
inject_message function and get it from opdata again after calling
otrl_message_fragment_and_send? I haven't tested it now, but that
sounds like it should work, thanks for pointing out.
But what I'd prefer is that inject_message doesn't return void but
void*, so one could return arbitrary data (in this case it's the stanza
ID) and then some way to get that return value from the function called.
> So your inject_message function could set *(XmppId *)opdata = id and
> you would have access to that when the call to otrl_message_sending
That sounds good enough for me.
> But I thought XMPP didn't need fragmentation, anyway?
XMPP itself doesn't, but it's possible to use ICQ through transports
via XMPP, thus you'll need it then.
> 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.
I guess this will give problems with ICQ through transports.
If otrl_message_fragment_and_send returns the fragments, wouldn't be
another possible way to send those fragments manually? That would have
the advantage that I get the ID of every sent message, not only the
first / last ID. That would be a big advantage, as we could request a
receipt for every fragment seperately then.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the OTR-dev