[OTR-dev] Re: Requirements for libotr4
ian at cypherpunks.ca
Fri Jun 20 09:37:25 EDT 2008
On Fri, Jun 20, 2008 at 08:39:38AM +0200, Kjell Braden wrote:
> On Thu, 19 Jun 2008 22:42:46 +0200, Jonathan Schleifer
> <js-otrim at webkeks.org> wrote:
> > The client *DOES* now the maximium MMS, so if it's per-conversation, i
> > works.
> > If a message is too long, it's silently dropped by the ICQ gateway.
> > This is really bad behaviour anyway, but all gateways seem to handle
> > it like this. The max. MSS seems to be really small on ICQ without
> > direct connections. And I don't know of any ICQ gateway taht uses direct
> > connections.
> As Uli pointed out, this is my fault: I statically returned 0 from the MMS
> calback. Looks like I forgot a TODO-comment.
Ah, OK. :-)
> Ian wrote:
> > We want to display *something* to the other user if he doesn't have OTR
> > installed, though. Are you suggesting each IM client can provide its
> > own text here? That would be OK, I suppose. We'd need another
> > OtrlMessageUiOps callback for that.
> no! It's enough to just switch to *one* callback that translates *all*
> strings (forgive me if I got you wrong and this is what you're suggesting).
> We would use it to do error messages as well as this announce message.
The callback won't be translating strings at all; libotr won't contain
any strings. [Exception: we'll supply default strings (or maybe just a
default callback) for the aid of client implementors that don't want
to have to deal with it themselves.]
For weird conditions that have to be reported to the user, the client
will get a callback like
report_event(opdata, context, OTRL_EVENT_UNENCRYPTED, message)
and it's up to the callback implementor to do whatever is necessary
(display "The following message was not encrypted: [%s]" to the user,
A separate issue is that when libotr wants to start an OTR session,
it sends an OTR Query message to the other side. This has to contain
the query string (?OTR?v2? for example), but can also contain whatever
other helpful text that the buddy will see if she doesn't have OTR
support. Right now, it calls the routine
otrl_proto_default_query_msg(ourname, policy) to generate this message.
What I'm suggesting is that an application can optionally override this
with a callback. [The callback would be responsible only for the text,
not for the ?OTR?v2? part.]
Is that clearer?
> Thanks for clarifying the conversion issue, I think I finally got it. This
> resolution seems okay with me.
More information about the OTR-dev