[Gossip-dev] Re: [Telepathy] GossipProtocol problems

[Xavier Claessens]

>
> >>>> 4) _is_valid_username, _get_example_username, _get_default_server and
> >>>> _get_default_port: doesn't seems to have an equivalent in
> telepathy...
> >>>> maybe it should be added to the specification ?
> >>> The default for anything that has a sensible default can be found in
> >>> ConnectionManager.GetParameters(). Sample values are mentioned in your
> >>> previous mail to the Telepathy list and the replies to it, but I'll
> repeat
> >>> for the benefit of other Gossip people: we don't have that
> functionality,
> >>> but perhaps we should.
> >>>
> >>> Validating parameters as best we can before actually attempting
> >>> registration would perhaps be a nice thing to add too. (I assume
> you're
> >>> looking for "live" validation as the user types in parameters?)
> >> Yeah would be nice to add a method which gets in argument a dictionary
> >> with all parameters/values and checks if values are correct, then
> return
> >> a dictionary with incorrect parameters/default-value (or
> >> corrected-value ?)
> >
> > As for some of the validation, I don't see a huge problem of having it
> > in Gossip. Gossip will know what backends it supports anyway and having
> > implementing some of these (preferably not default server/port) would be
> > okay to do within the Gossip code.
>
> We definitely need translated parameter naming so it is user friendly
> (i.e. instead of "old-ssl").
>
> 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.
>
> Most importantly we would need a method to validate parameters in real
> time.
>
> All of this probably fits into the spec that Telepathy is going to be
> designing for the mission control application.


I think for the UI we need:
  - an example for each parameter. examples are better than default values,
for example for the port it shouldn't have a default value (like that if
unset the CM can use 5223 or 5222 depending on old-ssl) but should have an
example to tell the user in the UI what a port looks like... It can fit in
the .manager file like that:
        example-account user at jabber.org

 - A translated name and description for each parameter. Like that in the UI
we can set a tooltip explaining what does the parameter.


Would be cool to have all this in the upcoming spec.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.imendio.com/pipermail/gossip-dev/attachments/20061016/5f7a254f/attachment.htm