[OTR-dev] Requirements for libotr4

[Jonathan Schleifer]

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
> completes.

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.

-- 
Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20080618/76c46145/attachment.pgp>