[OTR-dev] Requirements for libotr4

Kjell Braden fnord at pentabarf.de
Wed Jun 18 14:52:14 EDT 2008


On Mi, 2008-06-18 at 16:47 +0200, Jonathan Schleifer wrote:
> Ian Goldberg <ian at cypherpunks.ca> wrote:
> 
> > 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.
> 

Clarification: otrl_message_fragment_and_send does return either the
first or the last or no fragment, and sends all the others. It does not
split the message into multiple fragments and returns all of them.

The opdata thing would work, although the opdata is being abused for
quite a lot of stuff in gajim-otr currently, but that's not really a
problem in python (dictionaries, wooohoo!). We would need to rely on
libotr not using threads when calling the callbacks, so that the opdata
actually contains all the msgids when the libotr call (ie.
message_fragment_and_send) finished.
Gajim would have to be able to process multiple msgids and not only one,
because eg. in XEP-0184 it would not be enough to know that the
recipient received *one* fragment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20080618/2af9da79/attachment.pgp>


More information about the OTR-dev mailing list