> 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. _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
