[Bug 29375] New: add something resembling GabbleBaseChannel

[bugzilla-daemon at freedesktop.org]

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

           Summary: add something resembling GabbleBaseChannel
           Product: Telepathy
           Version: git master
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: medium
         Component: tp-glib
        AssignedTo: telepathy-bugs at lists.freedesktop.org
        ReportedBy: simon.mcvittie at collabora.co.uk
         QAContact: telepathy-bugs at lists.freedesktop.org


In principle, it's obviously a good idea for GabbleBaseChannel to move to
telepathy-glib, so that connection managers don't have to keep reimplementing
GetHandle().

In practice, it's more subtle than that, because GabbleBaseChannel encapsulates
a certain spec-compliance level: you must have well-defined values for
Requested, InitiatorHandle, etc. to use it. If we add more functionality to
Channel (perhaps ConversationID from one of the proposals in Bug #26838), we
have to be careful to get the backwards compatibility right in the base channel
class.

As a result of that sort of issue, I'd like to avoid having BaseChannel be
mandatory: in particular, TpBaseConnection and channel managers should be in
terms of TpExportableChannel (a GInterface that anyone can implement), with
BaseChannel just being a sample implementation.

11:04 < sjoerd> smcv: what do you think of moving gabbles base channel to 
                tp-glib ?
11:06 < smcv> sjoerd: a bit tricky, we need to be clear that it's not suitable 
              for everyone
11:06 < smcv> sjoerd: it represents a "compliance level", so TpBase018Channel 
              or something
11:06 < sjoerd> In which cases is it not suitable ?
11:06 < smcv> the CM supports more properties than spec 0.18
11:07  * smcv looks at the code
11:07 < sjoerd> so that's a hypothetical future issue
11:08 < sjoerd> e.g. you mean more properties on the Channel interface right ?
11:08 < smcv> right, but one that affects the choice of naming
11:09 < smcv> I don't want to get into a situation where we have TpBaseChannel 
              and TpBetterBaseChannel, and you're actually meant to use the 
              latter :-)
11:10 < sjoerd> the problem we can't add more properties to the base channel is 
                because of property naming right ?
11:10 < sjoerd> e.g. a subclass might have a property with the same name as we 
                might add
11:10 < smcv> right, adding a property that a subclass already has => explodes
11:11 < smcv> also, for some properties there's no sane default
11:11 < smcv> e.g. Requested
11:11 < smcv> "I don't know" is a value, distinct from either True or False
11:11 < smcv> (which we forbid in modern CMs)
11:11 < smcv> if the base class claims to know something but actually we have 
              no idea, then that defeats backwards compat
11:12 < sjoerd> that would be a matter of a switch which says whether to expose 
                a certain property on dbus though
11:12 < smcv> I suppose so

-- 
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.