[Telepathy] tp-qt4 high level channel API sketch

[Olli Salli]

On Fri, Jan 30, 2009 at 8:27 PM, Andre Moreira Magalhaes
<andre.magalhaes at collabora.co.uk> wrote:
> Hi,
>
> Simon McVittie wrote:
>> I think Channel could benefit from having accessors for targetID(),
>> isRequested() and initiator() (a nullable Contact object) too.
>>
>> Requested is a little tricky because it has to be a tri-state - on old
>> connection managers, we can't know whether the channel was requested or
>> not!
>>
>>
> Hmm, I will add the extra methods, there will probably be more methods
> there that we are missing here.
> The idea of this sketch was just to see if the idea of splitting
> channels in specialized classes was acceptable, which I think it is.
>
>> On Fri, 30 Jan 2009 at 11:37:47 -0300, Andre Moreira Magalhaes wrote:
>>
>>> class GroupChannel : Channel:
>>>
>>
>> Many channels are (at least potentially) a Group so I think this is
>> unnecessary - just fold it into the Channel class and have it not always
>> be relevant.
>>
>>
> Yes, actually the first version I wrote here, was like this with the
> group functionality inside the Channel class itself, but then I changed
> it to be a separate class to make it more user-friendly IMHO, but I can
> revert that if you prefer.

I prefer having the Group functionality on all Channels rather than
only on "GroupyChannels". Makes for more uniform handling of
participants for any kind of communication (1-1 chats, irc chatrooms,
calls...) in user code.

>
>> I think we agreed earlier that channels whose TargetHandleType is Contact
>> should fake being a Group with two members ("us" and "them"), even if at
>> the D-Bus level they're not.
>>
>>
> Yes, that will be done, I just didn't wrote it. The group will always
> have at least 2 members.

See previous. Also, when Group is faked on all channels, there's no
reason to not have it in the main Channel class at all - all Channels
will be a Group, so all channels should expose that Group.

>> I don't think exposing the Contact List channels to library users is useful.
>> Adding "roster" functionality to Contact objects is already in the outline in
>> my "sketches" branch - that seems a much better API for the same thing.
>>
>>
> I really prefer having a ContactList channel that in reality is just a
> Group Channel, or if we change a Channel itself. It's easier for users
> IMHO to understand, They will add/remove contacts using addContact,
> removeContact, get all contacts using local/pendin/...Members
>
> But that's your call.

Mine too ;P My 2 cents being really similar to Simon's. It turns out
that the add/remove concepts aren't very self-explanatory for the
contact lists. And neither is the fact that you need to get a channel
to get the list of your contacts very obvious. I think we have plans
to change this even at the D-Bus level to be more like "contacts
having subscription/... flags and groups " than the current "channels
for subscription/... and groups having contacts" model when we get
closer to Telepathy 1.0.

Examples:
 - addContact doesn't make sense on "publish" unless the remote is on
the local pending list - which not very obviously means they want to
see your presence - and it's not really obvious either that in that
case, it means "allow this guy to see my presence"
 - remote pending doesn't make sense on "publish"
 - ... same for local pending on "subscribe"
 - neither of these does make sense on "allow" and "deny"
 - interactions between eg. the allow and deny lists are hard to
present (if you add a contact HERE, he will disappear from OVER THERE)

>
> The thing is, it seems the basic idea is approved, the idea to split it
> in several specialized channels and then return them to the users.
> I will start working on this, I just would like to set first if we are
> going to join Channel and GroupChannel, I am really not sure which one
> is more friendly.
>

OK, cool. Waiting for your branch to see how that turns out :)

> BR
> Andrunko
> _______________________________________________
> Telepathy mailing list
> Telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>



-- 

Br,
Olli Salli