Re: Data messages

On Thu, 2004-06-24 at 18:28 +0100, Meredydd wrote:
> On Thursday 24 June 2004 17:47, Rodney Dawes wrote:
> > On Thu, 2004-06-24 at 17:21 +0100, Meredydd wrote:
> > > CCing this back to the list, as I'm not the only one with an
> > > interest in this (sorry, this list doesn't munge reply-to).
> >
> > Heh. Use "Reply to All" next time? :)
> Indeed, you should have done.

I pretty much always use Reply to All. :) But we don't need to spend
time arguing about it, unless you really want to waste time so I can
prove you wrong, even if it was just your mail client being stupid at
some point. :)

> > > Umm...what do you mean by that? HTTP Auth is a crummy model, in my
> > > opinion, because it's designed to carry authentication over a
> > > request-based protocol, with the wrong party (the client rather
> > > than the server) initiating...
> >
> > I meant the Domain/User/Password model. 
> Oh, right. Um, I'm not so sure about that, actually - it doesn't fit too 
> well into what we've got. The user/domain part is pretty fixed, given 
> that  handle+service is the unique ID of a local account. All we really 
> want is a password, isn't it?

But you need to request the password from the UI. And the UI needs to
request it from the user. And the user needs to know what password to
use. I was bringing it up, because the domain/user/password auth model
is similar to how gnome-keyring works for doing the storage/lookup. So
something close to that where large amounts of extra code don't have
to be written to make something simple like this work, would be good.
If you just give me the user and service when requesting the password,
that is probably good enough, and I can turn that into the necessary
info to use with gnome-keyring.

> > > Hmm. Incidentally, what do you need from the core before you can do
> > > that?
> >
> > The UI needs to be able to get buddy icons.
> Oh, wibble. This is going to be...interesting. None of the service 
> *libraries* currently support buddy icons, let alone the core plumbing.

Jabber should be easy to add code to to support buddy icons, since it is
just an XML protocol, and is very Open.

> * AIM/ICQ - using an old, effectively orphaned TOC library.
> To support buddy icons: We would need to integrate libfaim or something 
> like it.

Yeah. Once we get libfaim, I might actually be able to reliably connect
to AIM/ICQ with eb-lite. :)

> * MSN - Using my libmsn, which has now been taken over by Mark Roww.
> To support buddy icons: Mark needs to implement handling for the SIP 
> bits of MSNP8. This is...non-trivial.

I don't know how the MSN stuff works. I guess it doesn't really have
buddy icons, but instead has the slideshow images thing that's on the
side of the chat window (in MSN Messenger 6). These images probably
are going to generally not be in the same aspect ratio as 48x48, and
thus will probably suck as buddy icons in reality.

> * Yahoo - Using libyahoo2, Craig's patch. Does Yahoo even support buddy 
> icons? I know it supports webcams, and I suppose it would be possible 
> to use the last webcam image, but can we do any better?

We could fix either libyahoo2 or the plug-in itself to look up the
user's profile page, screen read it, and grab their picture, if there
is one. Of course, this will also kind of suck a little bit, since the
pictures are generally not in the 48x48 aspect ratio either.

> * IRC - Does not support buddy icons.

Yeah. IRC doesn't support a lot of things. :)

> There's also the matter of possibly emulating buddy icons for services 
> which don't support it...

Yes. Senility will store the images in the evolution-data-server address
book code anyway. So even if the service doesn't support it, if you have
an icon set for someone in your address book, it will get used as the
buddy icon, if it is of an appropriate aspect ratio, or not far from it,
I think.

-- dobey