[Telepathy] TpHandler

[Sjoerd Simons]

On Wed, Nov 25, 2009 at 12:47:48AM +0000, David Laban wrote:
> 
> > 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:

As some background, (lib)empathy works as follows: There is one singleton
dispatcher object that exists for the lifetime of the process, this dispatcher
object has one main handler head which will never go away. (In empathy this has
the channelfilter that matches the .client file). You can dynamically add and
remove extra heads, with whatever filter you like.

These HandledChannels property on the main head has all the channels
that are currently being handled, the HandledChannels property on the other
heads return an empty. (This is indeed not spec compliant).

When a new channel comes in via whatever head, this channel goes into the main
dispatcher, which checks if we requested ourselves and if so calls the callback
of that requestor.

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

We probably want a nice GAsync style functions for creating and ensuring
channels which you give all the information you ever want and gives you a nice
fresh channel at the end. It's debatable whether you need to confirm that
you're actually going to handle this channel.  If you use the function which
can give you a channel back, you basically promised that you'll take good care
of it.

On a technical level, if you don't want to handle the channel your requested
you also don't need a Handler Client. So the function to request channels that
you don't necessarily want to handle that doesn't have much to do with Handlers
at all :)


One thing we should make easy for client code is to be able to distinguish
between Channels they got because it asked for them or Channels they got
because they're picked as the handler for some other reason. For example in
empathy the requesting code first gets a chance to claim the channel internally
and only if it doesn't it gets dispatched through the rest of it.

> Should the channel fulfilling this request be auto-accepted? 

Yes, if you asked for the channel and said that you wanted to handle it you
should handle it.

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

That should never happen.. The fact that butterfly is strange with an anonymous
Text channel that does have a group interface is a mistake, which should be
fixed asap.. In general if either the CM is buggy or you weren't paying
attention when you requested a channel (e.g. you requested an FT channel, but
you get one back which requires a hashing function you can't do), then your
free to close the channel directly.

  Sjoerd
-- 
IN MY OPINION anyone interested in improving himself should not rule out
becoming pure energy.
		-- Jack Handey, The New Mexican, 1988.