[OTR-dev] Re: Requirements for libotr4

[Kjell Braden]

> 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,
> for example).
> 
> 
> 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?

My idea was this:

The lib calls a callback like:

humanize_string(&human_message, OTRL_MSG_EVENT_UNENCRYPTED, message)
and send the resulting human_message to display_otr_message.

Same for the Query Message: otrl_proto_default_query_msg (or whoever)
goes like:
humanize_string(&human_message, OTRL_MSG_QUERY)
and returns the resulting human_message.