[OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message

Scott Ellis mail at scottellis.com.au
Wed Feb 22 19:16:02 EST 2006


On 23/02/06, Ian Goldberg <ian at cypherpunks.ca> wrote:
>
> On Tue, Feb 21, 2006 at 08:08:37PM +1100, Scott Ellis wrote:
> > > >I'm not sure I understand here.  It looks like you're passing the
> string
> > > >"OTR" as the first parameter to otrl_proto_default_query_msg() when
> the
> > > >user selects "start OTR" instead of passing the account name.
> >
> >
> > Yes that's what i pass in. In miranda there aren't different accounts -
> only
> > different protocols. It is possible to have e.g. two MSN 'accounts' but
> you
> > do that using a 'hack' - i.e. you copy the msn.dll plugin to msn2.dll or
> the
> > like, and miranda treats it as a seperate protocol.
>
> Wow.  That *is* a hack.  Surely there's a way to extract your account
> name, though?


There really isn't the concept of an account name in miranda...I can get the
protocol name, or the protocol unique identifier (e.g. UIN) which may not be
human readable...or, which is about the closest thing, the name of the
user's database file - but that is often 'default' or something like that.

I guess what I'm suggesting is that the library do some processing of the
query message even when the policy is 'never'.

> So, in the plugin there
> > is only one account - i called it OTR, since i didn't think it'd make a
> > difference. What I meant to point out is, since the username is passed
> into
> > that function also, shouldn't the username be used in this message?
>
> The remote username?  That's not passed in:
>
> /* Return a pointer to a newly-allocated OTR query message, customized
> * with our name.  The caller should free() the result when he's done
> * with it. */
> char *otrl_proto_default_query_msg(const char *ourname, OtrlPolicy
> policy);


Sorry, I mean't the username is passed into the 'receieve' function, on the
receiver side - i misunderstood your last post regarding that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20060223/a9a7b0e0/attachment.html>


More information about the OTR-dev mailing list