I'm trying to implement this but TpChannelManagerTypeForeachChannelClassFunc doesn't give us the self pointer of the manager, so we can't get the default server with _gabble_connection_find_conference_server(); which is pretty annoying. :\

(In reply to comment #1)
> I'm trying to implement this but TpChannelManagerTypeForeachChannelClassFunc
> doesn't give us the self pointer of the manager, so we can't get the default
> server with _gabble_connection_find_conference_server(); which is pretty
> annoying. :\

That's because TpChannelManager *Type* ForeachChannelClassFunc is a 'static' version (in Java terms): it operates on the type, not on instances of it.

Gabble could also implement 
TpChannelManagerForeachChannelClassFunc foreach_channel_class; which does give you the self pointer. This would mean we'd have more classes once connected, which is correct!

(However… I think RequestableChannelClasses can't change once you're connected, so I suppose we'd have to not signal Connected till we've discovered the conference servers… which would be unhappymaking.)

(In reply to comment #2)
> (However… I think RequestableChannelClasses can't change once you're connected,
> so I suppose we'd have to not signal Connected till we've discovered the
> conference servers… which would be unhappymaking.)

You' right: http://telepathy.freedesktop.org/spec/Connection_Interface_Requests.html#Property:RequestableChannelClasses

So we basically have 2 options here:
- Expose the servers in the RCC and delay CONNECTED until we discovered them
- Add a property + change signal.

Note that we'll have exactly the same problem if we want to expose contact-search servers (which I think we should).

I think the two requestable channel classes that make sense for room lists are "a room list with an arbitrary DNS name" and "the single default room list". If we want lists of suggested "nearby" room list and contact list servers, they should be informational properties, not part of a requestable channel class, IMO.

Perhaps we could have a Conn.I.SuggestedServices or something, which is basically the same concept as Jabber disco? "These services are attached to our home server or recommended by our sysadmin, please offer them to the user", basically.

(In reply to comment #4)
> I think the two requestable channel classes that make sense for room lists are
> "a room list with an arbitrary DNS name" and "the single default room list". If
> we want lists of suggested "nearby" room list and contact list servers, they
> should be informational properties, not part of a requestable channel class,
> IMO.

Atm Gabble has only one RCC:
({ ChannelType: RoomList, TargetHandleType: None}, [Server])

Should we have
({ ChannelType: RoomList, TargetHandleType: None}, [])
as well for the "default" case?


> Perhaps we could have a Conn.I.SuggestedServices or something, which is
> basically the same concept as Jabber disco? "These services are attached to our
> home server or recommended by our sysadmin, please offer them to the user",
> basically.

Yes that could do the job. Using an a{sv} I guess:

Conn.I.SuggestedServices = {
  'org.freedesktop.Telepathy.Channel.Type.RoomList.Server': ['server1', 'server2'],
  'org.freedesktop.Telepathy.Channel.Type.ContactSearch.Server': ['badger']
}

With the semantic that the first element in the list is the one used by default.

My use case is basically displaying a default server in the GtkEntry allowing user to define its own server.

(In reply to comment #5)
> Atm Gabble has only one RCC:
> ({ ChannelType: RoomList, TargetHandleType: None}, [Server])

Sorry, yes, I'd misremembered. One RCC is sufficient, and we can use presence or absence of Server in Allowed to choose between the two possibilities.

Retitling. This needs spec work.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/126.