[OTR-dev] Re: SMP state machine broken?
a.sporto+bee at gmail.com
Wed Jun 4 17:13:29 EDT 2008
thanks for your answer, I do see things more clearly now :)
On 2008-06-03, Ian Goldberg <ian at cypherpunks.ca> wrote:
> This is part of the current API problems we're working on cleaning up.
> Right now, there's some stuff libotr does for you, and some you need to
> do in the calling application. This was done to avoid adding another
> callback (since the application, not the library, needs to handle
> certain cases), but I agree that it's very messy, and one or more
> callbacks will be the way it'll be handled in v4.
That sounds like a good idea to me.
> For now, see the UPGRADING file in the libotr source to see how to add
> the necessary support into your application.
That file was indeed my only source of information when implementing
SMP and I see now that the code snippet in there is meant as a
template for applications and not (as I understood it) as a
description of the libotr implementation. What misleaded me was that
it is first said
"You may access context->smstate->nextExpected to find out
which TLV should come next"
and then it says
"A typical control flow looks like this:"
Because of this introduction and the fact that nextExpected is not
only read but also written to in the code snippet I assumed this is
libotr code. I imagine other people could misunderstand this as well.
> Also, you can find the current cvs at sourceforge:
Thanks! One thing I noticed in the diff to 3.1.0 is that apparently
something like s/3.1.0/3.2.0/ was applied to the code which lead to a
passage that states that fragmentation was introduced in 3.2.0. I'm
guessing that is not meant to be.
More information about the OTR-dev