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

[Eitan Isaacson]

On 10/15/06, Mikael Hallendal <micke at imendio.com> wrote:
> Xavier Claessens wrote:
>
> Hi,
>
> > Le dimanche 15 octobre 2006 à 02:07 +0100, Simon McVittie a écrit :
> >> On Sat, 14 Oct 2006 at 22:20:43 +0200, Xavier Claessens wrote:
> >>> 3) _register_[account,cancel]: doesn't have an equivalent in telepathy.
> >>> As I understand teleapthy, accounts have a "register" parameter, is it's
> >>> set to TRUE we connecting this account, telepathy will automatically
> >>> register the account.
> >> Yes. However, you can't rely on this working, even for XMPP (Google
> >> Talk only accepts registrations over the web, I believe) and other
> >> protocols might not be able to do in-band registrations at all.
>
> Isn't there a way to ask the server before trying whether it's
> supported? If not, I guess we could at least make it so that protocols
> we know for sure don't support it doesn't show us that option in the UI
> and for others (XMPP) we try and if that doesn't work we show an error.
>

No need for too much guesswork here. One of the flags the connection
manager returns when it lists parameters is if a certain parameter is
needed for registration. If one or more parameters have that flag,
then we present a registration option in the UI. Like Xavier said.

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

I agree, although in a perfect implementation we really shouldn't have
anything protocol-specific in the code.

>
> >>> 5) _is_ssl_supported: useless, just check if there is a parameter like
> >>> "old-ssl" in the account.
> >> Parameter naming may vary per CM, I think old-ssl is specific to Gabble.
> >> When we eventually support TLS/SASL for XMPP, things will be somewhat different
> >> there anyway.
> >
> > This is mainly used in gossip to know if default port should be 5222 or
> > 5223, but as said somewhere else it can be solved by simply not fill the
> > port and let the CM set the default value.
>
> Agreed that we can probably live without this one.
>
> >>> 6) _send_composing: Don't know if it's supported by telepathy ?!?
> >> As Daf said, it's not currently, although it's been discussed.
>
> Yeah, this is a requirement from our point of view.
>
> >>> 7) _get_active_resource: how can it work with protocols that doesn't
> >>> support resources ?
> >> It can always return a null string, or something? We don't have any
> >> support for multiple resources in the Telepathy spec at the moment, and
> >> it will never make sense for many of the non-XMPP protocols.
> >
> > would be cool to have a spec for this, even if it just returns an empty
> > list on other protocols than XMPP.
>
> Same here, it's a requirement. Protocols that don't support it can just
> return NULL or something and we can simulate only having one resource in
> the Gossip layer.

I don't believe this is necessary. What does gossip use this function
for besides choosing which resource to send the IM to? This is
determined by Gabble anyway. With Gossip's current functionality there
is no real need for a Telepathy resources interface. If you decide in
the future to allow the user to choose the resource he sends IMs to,
then it would be necessary.

>
> Thanks Xavier for putting together this list.
>
> Cheers,
>   Mikael Hallendal
> --
> Imendio AB, http://www.imendio.com/
> _______________________________________________
> Gossip-dev mailing list
> Gossip-dev at lists.imendio.com
> http://lists.imendio.com/mailman/listinfo/gossip-dev
>
>