Re: Data messages

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).

On Thursday 24 June 2004 16:19, you wrote:
> On Wed, 2004-06-23 at 13:01 +0100, Meredydd wrote:
> > On Monday 21 June 2004 03:03, you wrote:
> > > As far as I can tell from the GUI_SPEC file and the gui_comms.c
> > > file in src/, all that is theoretically possible with this, is
> > > the sending of data over a stream, not necessarily the attaining
> > > of data being sent to you, or arbitrary data that might get
> > > received on log-in such as the cookies from yahoo/msn.
> >
> > Indeed. Prod me! I'm working on an out-of-band comms system which
> > we could use for things like these cookies, and I'm trying to think
> > my way around password management. Possibly something which a
> > service plugin can call, which would obtain the password by
> > whatever means necessary and then call a callback. Do you reckon we
> > should do this on a per-local-account basis, or expand it to a
> > generic set of passwords, keyed to particular strings? And if it's
> > the latter, perhaps this should be linked to password fields in the
> > proferences? That might be a little nicer, really...
>
> I am not sure. Something similar to how basic auth with HTTP works
> would probably be good.
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...

> We shouldn't force passwords to get stored in 
> the preferences, unless the user wants to, with a UI that supports
> storing them there.
That's what I mean. What failed to express there was that I'm 
considering adapting the preferences system to make each preference of 
type "password" merely a reference to a key in a password-keeper 
system, which would then handle all the stuff you're talking about.

> Senility, for instance, will not, as it will use 
> the gnome keyring stuff, and if the user wishes, their passwords will
> get stored there. We should check to see if the password is stored,
> and use that. If it is not stored, or fails, we should send some
> message to the GUI to ask for the password.
That's the plan. I'm thinking that all passwords, or 
spaces-where-passwords-can-be (if you know what I mean), should have a 
unique ID. There should be GUIcomms commands to store or erase values 
for these in the core, and for the core to request values from UIs. A 
"password" pref would then just become a reference to an entry in this 
table.

> > Also expect a special set of generic pref pages indicating which
> > information should be provided for a new local accounts with each
> > particular service.
>
> Good. :)
>
> > > What is the plan for handling that
> > > sort of stuff? It would be nice to start getting some of that
> > > done, so I can do some neat little things in Senility with
> > > regards to integrating in the Gnome desktop.
> > >
> > > Such as plunking buddy icons into the address book for contacts.
> >
> > Now that would be neat
>
> Indeed. It is neat.
Hmm. Incidentally, what do you need from the core before you can do 
that?

> > > As for the inline image messages, how does one actually receive
> > > them?
> >
> > Um, oops. That should be documented, as should what happens when
> > they get held. I'll commit the changes to GUI_SPEC today, with
> > luck.
>
> I'll look it up.
Not yet, it's not committed :-P

>
> > But right now, I must vanish, on account of having my last A-level
> > exam. Ever. Boy, does that feel good ;^)
>
> Hope it went well.
It did indeed. A-levels, what are they? ;^)

Meredydd