[Telepathy] TpHandler

[David Laban]

> Please look at telepathy-qt4, whose Tp::AbstractClientHandler class 
implements
> telepathy-spec without its users having to jump through hoops, before going
> further with this class. We've designed many of the subtleties once already,
> there's no need to do it all again :-)

This may be slightly orthogonal but related. Just something to keep in mind:

When smcv+sjoerd+alsuren discussed the Client stuff in Cambs, sjoerd pointed 
out the following use-case that a convenience library should be compatible 
with:

"I want to request a text channel to this person, and have this function 
called back."

Should the channel fulfilling this request be auto-accepted? 

What happens when we request a text channel and get sent back a MUC?

The answers to these questions lie in my purple notebook, which I don't have 
to hand. My parents probably wouldn't appreciate me turning the house upside 
down at this time of night to find it so I'll try to remember what was said. 

I think we decided that if the client doesn't understand mucs, it should be 
given the chance to accept/reject/destroy it. 

If a channel is created to satisfy a request, and it doesn't actually satisfy 
it (i.e. the client doesn't understand the channel type) then it should be 
shot in the face rather than being left to be handled by another process. (I 
can't think of the example that was given, but if you request a game of chess 
and abiword pops up you're going to be a bit confused. Similarly if your app 
is supposed to stream 2girls1cup to someone and post their response to 
youtube, you probably don't want to end up in an actual video call)

If anyone remembers any more, feel free to correct me.