[Bug 48210] Could TpBaseChannel be more flexible?

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed May 30 16:09:48 CEST 2012


https://bugs.freedesktop.org/show_bug.cgi?id=48210

--- Comment #5 from Jonny Lamb <jonny.lamb at collabora.co.uk> 2012-05-30 07:09:48 PDT ---
The big use case I want this for is when a MUC text channel appears but only
for a "sub-channel" (such as a Tube). This is what I want:

the setup:

   1. a DBusTube MUC channel is requested.
   2. gabble has to connect to the XMPP MUC and it does so.
   3. a GabbleMucChannel is created internally, but is not exposed or
      announced on the bus at all.
   4. a GabbleTubeDBus is created and the DBusTube channel is exposed
      and announced.

use case #1:

   a. a Text MUC channel (to the same MUC) is requested
   b. the GabbleMucChannel already created is exposed and announced
   (time passes)
   c. the Text channel has Close() called on it; it is Closed()
   d. the DBus tube channel is still open and in use
   e. hence the GabbleMucChannel hides again

use case #2:

   a. a message appears in the MUC sitting around hidden inside gabble
   b. the GabbleMucChannel is exposed and announced
   (time passes)
   c. the Text channel has Close() called on it; thus it is Closed() and
      disappears from the bus
   d. the DBus tube channel is still open and in use
   e. hence the GabbleMucChannel hides again

Then this can go around in a circle. Use cases #1 and #2 are actually the same
path, but they are the cases in mind. So if I tried to implement this now with
what's available in TpBaseChannel, this is what I would do:

the setup implementation:

    * create a GabbleMucChannel, don't register(), emit_new_channel()
    * create a GabbleTubeDBus in said muc channel,
      *do* register() and *do* emit_new_channel()

use case #1 and #2 implementation:

    * register() and emit_new_channel() on the existing GabbleMucChannel
    (time passes)
    * the text MUC has been closed; if we call destroyed() here, the
      channel manager will dispose of the MUC and its tubes. if we call
      reopened it'll "close" but then reappear... we don't want that
      either. we want to emit_closed(), emit_channel_closed() and
      unregister()


Does that make more sense as to why we need the text MUC to be able to
disappear?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.



More information about the telepathy-bugs mailing list