[OTR-dev] Re: Requirements for libotr4

[Evan Schoenberg]

On Jun 20, 2008, at 9:55 AM, Ian Goldberg wrote:

> On Fri, Jun 20, 2008 at 03:43:57PM +0200, Kjell Braden wrote:
>> 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.
>
> But the application may not want the result to just be a string passed
> to display_otr_message.  It might want to change some chrome in the  
> UI,
> pop up a message box, or do something else entirely.
>
> Your suggestion also has the effect of forcing there to be a second
> callback to free the memory allocated by the first callback.  (See the
> account_name and account_name_free callbacks, for example; hey--come  
> to
> think of it, those will be able to go away with the new scheme.   
> Nice!)

I agree strongly with Ian.  libotr shouldn't care about getting human- 
readable strings from the UI in at least the vast majority of cases if  
not all cases.  The UI gets a value out of an enum via a callback and  
presents this information however it chooses.  Only with the 'default  
OTR' message do I see a need for returning a human-readable string. I  
have no problem with the current default string, but on the basis that  
one's contacts most likely speak one's language it makes sense for  
this to be localized by the sending client.

Cheers,
Evan