Introspect Blocks

[George Kiagiadakis]

On Fri, Jul 20, 2012 at 2:07 PM, Puneet Goyal <puneetgoyal08 at gmail.com> wrote:
> If we are going to keep it in ktp-common-internals or telepathy-qt where we
> cannot use QDBusConnectionPrivate class we will only be able to provide the
> info about the object paths that we register using our registerObject
> method. Even according to the dbus-specifications we mainly need the
> properties of the interfaces so that no call the org.freedesktop.properties
> interface is made.

Please avoid top-posting.

>
> On Fri, Jul 20, 2012 at 12:51 PM, Daniele E. Domenichelli
> <daniele.domenichelli at gmail.com> wrote:
>> On 20/07/12 02:06, Puneet Goyal wrote:
>>>
>>> Can I use the QDBusConnectionPrivate class somehow??
>>
>>
>>
>> It depends from where the org.freedesktop.DBus.ObjectManager interface
>> will be at the end.
>>
>> We have 3 options:
>>
>> 1) Have in *ktp-common-internals*. This is the easier way to get it merged
>> somewhere, but you cannot use the QDBusConnectionPrivate class, you must
>> instead implement a registeObject method (and an unregister one too) similar
>> to QDBusConnection::registerObject instead, and you have to call it every
>> time you call that method

I would go for this one for the moment. It's the easiest goal. And if
the API is really good, we can consider moving it to telepathy-qt. It
doesn't matter much if we need a different registerObject method.

>> 2) Try to merge it in *telepathy-qt*. The implementation is the same, so
>> I'd forget about this at the moment, we can move it later if we realize that
>> it is needed by others.

Maybe, although if we had a higher-level DBusTubeServer/DBusTubeClient
api, similar to the stream-tubes one, maybe ObjectManager could be an
internal detail there...

>> 3) Try to merge it in *Qt5* and possibly in *Qt 4.8.next* since it
>> shouldn't add any new method. That's for sure the best place to have it, in
>> this way you get the ObjectManager for free in every dbus object (like for
>> the ofD.Introspectable and ofD.Peer interfaces). The implementation is going
>> to be easier, because you may use QDBusConnectionPrivate, but on the other
>> side it's going to be harder, because you cannot test it with qt from your
>> distribution but you need to build it from scratch, and because the code
>> should be of a very good quality to be merged in Qt. Moreover understanding
>> the internals of QtDBus is not an easy task. And finally the way to
>> implement it is going to be completely different...

This is obviously the best solution, but also the most unrealistic,
given that it is difficult to develop and difficult to get your code
merged (it needs to be some damn good code!).