Re: Re: [Telepathy] GossipProtocol problems

Martyn Russell wrote:
> I would be surprised if Gabble supports capability discovery yet.

Hm... we've had code to discover server features at connect time since
March, and besides this we also do disco queries to find the server's
available MUC servers, validate MUC room names, list available MUC
rooms, etc. We also reply to service discovery queries to our own JID
and implement entity capabilities (XEP-0115) to discover which of our
buddies we can call, and advertise our own callability.

> We definitely need translated parameter naming so it is user friendly
> (i.e. instead of "old-ssl").

The point of the standard parameter names as defined in the spec is that
you can ship translations for these and use them. If you don't know what
a parameter is, it's not

> We also would need default/example parameters for usernames/ports, etc.
> I think having no value is less informative and it doesn't harm to have
> it. We also make use of the example username in the username field
> (where it would apply on a per protocol basis of course) and select it
> so that users have a clue as to the format of the username.

Similar to above, you should probably just recognise which format of
account names different protocols have, and show an example if you know it.

> Most importantly we would need a method to validate parameters in real
> time.

That's the clincher, that's very tricky. For the old-ssl -> port
interaction, I'd suggest that Gabble could put the port to 5223 if
old-ssl was enabled and no port was specified. In general, the UI
shouldn't send the value to the connection manager unless it's been
changed from the default; and it should certainly never save the default
values at eg account creation time; otherwise you could clobber changes
which are made to the default values.

> All of this probably fits into the spec that Telepathy is going to be
> designing for the mission control application.

I'm not so sure all of these are "in-scope" for Telepathy itself;
possibly Mission Control or an associated component could do *some* of
this, but it's generally held that the thing responsible for
creating/configuring accounts of various protocols could have at least
some protocol-dependent code in order to correctly internationalize and
present a sane UI to the user, perhaps falling back on a best-attempt
generated UI.

In the Nokia 770 there is a concept of "profiles", which define further
defaults (eg google talk -> server:talk.google.com, port:5223,
old-ssl:true), protocol names, icons, vcard fields, UI plugin to use for
configuration, etc, for available protocols. This is not directly
relevant to the operation of the connection manager, and so is not
discoverable from the Telepathy D-Bus spec itself or the .manager files,
but is all useful stuff for presenting a reasonable UI. We could
consider doing something similar as part of the MC work.

Regards,
Rob