Proposing ObjectManager interface

[David Zeuthen]

Hi,

On Mon, Feb 28, 2011 at 11:04 AM, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> On Mon, 28 Feb 2011 at 10:37:05 -0500, David Zeuthen wrote:
>> [1] : for example, an object implementing the BlockDevice interface
>> will implement the Filesystem interface only if the block device
>> actually looks like a mountable filesystem.. and this changes as you
>> run wipefs(8) and mkfs(8) on the device.
>
> What's wrong with having /blahblah/sda1 (implements BlockDevice) and
> /blahblah/sda1/fs (conditionally present, implements Filesystem), or something?

Nothing at all except that it kinda conflates objects with interfaces
and thus kinda messes up what you want to see with e.g. d-feet(1) or
gdbus(1). There's nothing inherently wrong in that, it's just another
model just like using %73%64%61%31  (URI encoding) instead sda1 is
"different".  Or using a low-level binary protocol instead of the
D-Bus protocol is "different". At the end of the day, it's just a
matter of taste whatever you do (for better or worse).

> In Telepathy we get quite a lot of mileage out of the concept of "immutable
> properties", which are properties that are guaranteed to be good for the
> entire lifetime of an object (corollary: if they change, you have to signal
> it as destruction and (possibly atomic) re-creation). This gives us a couple
> of useful things:
>
> * major round-trip reduction, by announcing an object's complete set of
>  immutable properties in the same signal that announces its creation
>
> * instant object usability (synchronously-ready objects without making
>  blocking method calls) due to the above
>
> * in some contexts (mapping a Channel to zero or more loggers and UIs for it,
>  mainly), we allow arbitrary filtering (matching by equality) on the
>  namespaced a{sv} of immutable properties, which means a cooperating protocol
>  implementation and UI can arrange for that UI to get that protocol's
>  Channels without modifying the generic ChannelDispatcher
>
> I realise Telepathy's complexity is far from typical, though!

FWIW, I think this can be achieved with ObjectManager by marking the
property with the
org.freedesktop.DBus.Property.EmitsChangedSignal='false' annotation
and catching app-specific signals in client proxies to update its
value (if applicable). So, conceptually at least, ObjectManager could
be used with Telepathy (actually, you don't really need the annotation
- it's enough to just use a app-specific proxy) since it pretty much
does all this...

Then again, ObjectManager might not be the right fit for any
application and that's fine... Super-optimized, Easy-to-use, Versatile
- pick any two .. anyway... but the reason I want to standardize this
interface that it ObjectManager is efficient (only two calls are
needed: ObjectManager.GetAll() and Bus.AddMatch()) and easy to use (it
allows synchronization of entire forests of objects with properties
and signals) without having to programmer to worry about the things
that almost any D-Bus app get wrong (race-condition watching names,
protocol with tons of roundtrips). I think it's almost impossible to
do it wrong with the GDBus implementation of ObjectManager....

     David