On Mon, Nov 19, 2012 at 1:08 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Lucas, > > On Mon, Nov 19, 2012 at 3:18 PM, Lucas De Marchi > <lucas.demarchi@xxxxxxxxxxxxxx> wrote: >> On Mon, Nov 19, 2012 at 10:49 AM, Luiz Augusto von Dentz >> <luiz.dentz@xxxxxxxxx> wrote: >>> Hi Lucas, >>> >>> On Mon, Nov 19, 2012 at 2:06 PM, Lucas De Marchi >>> <lucas.demarchi@xxxxxxxxxxxxxx> wrote: >>>> Hi Luiz, >>>> >>>> On Mon, Nov 19, 2012 at 6:46 AM, Luiz Augusto von Dentz >>>> <luiz.dentz@xxxxxxxxx> wrote: >>>>> From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> >>>>> >>>>> This makes g_dbus_setup_bus to automatically register '/' path so >>>>> user application that don't export any interface on '/' will have it >>>>> registered for ObjectManager. >>>>> >>>>> Note that it is now required to call g_dbus_close before exit. >>>> >>>> I'm no really fan of this. Why do we need to register '/' now? If we >>>> are not going to support ObjectManager interfaces in subtrees, it >>>> would be easier to just move the ObjectManager to the shortest path >>>> registered rather than always registering '/'. >>> >>> Maybe I should have made clear this in the description, if you look at >>> the spec it suggest that each sub-tree root should implement >>> ObjectManager, the current implementation does that but if you think >>> about it probably doesn't make sense to have sub-trees because that >>> would creates extra round trips that ObjectManager was meant to >> >> HUmn... I think you are a bit confused now. >> >> 1 entire tree can be managed by a single ObjectManager, or multiple >> ones if there are objects that are not interesting to everybody and >> only a few types of clients would be interested in the objects changed >> beyond that path. >> >> Example: >> >> /org/bluez >> - ObjectManager >> /org/bluez/adapter/bla/bli >> - MyInterfaceWithLotsOfObjects >> >> If you put only 1 ObjectManager it means you get called for each >> change in /org/bluez/adapter/bla/bli even though most of the clients >> will not be interested in that. Therefore the spec allows you to >> attach another ObjectManager in /org/bluez/adapter/[...] so the first >> ObjectManager only send updates and "manage" the objects until the >> path containing another ObjectManager. >> >> I do think we don't really need that feature right now. I think we are >> fine with a single ObjectManager in "/", but always registering "/" >> IMO is not the right solution. > > As far I know /org/bluez/adapter/bla/bli is a child of /org/bluez thus > you don't need another ObjectManager, anyway the point is that Sure we don't need it, but it was made that way so projects could actually use multiple object managers for the reasons pointed out in the previous email. Projects could even have separate ObjectManagers for completely different things, like one in /org/bluez/bla and another in /org/bluez/bli instead of 1 in /org/bluez. But it's an application decision where to put the ObjectManager. If all projects using gdbus decide to have a single ObjectManager on "/" because it's simpler and fit the needs for everybody, then fine. I'd suggest to even register it earlier than it is. Otherwise we might choose to let the application (bluez, connman, ofono, etc) decide where to put it, by adding a "g_dbus_attach_object_manager(conn, path)" or the like. > multiple ObjectManagers for the same connection might not make sense > as it will create more round trips to discover the object tree e.g: > /org/bluez vs /org/somethingelse I'm not arguing about one object manager per object path component. > > There is also the problem of supporting changing the root, the spec > doesn't mention anything about that even though it says it can support > sub-trees thus the application could in theory register a new root > e.g. /org at any point which basically invalidates the entire > sub-trees which I don't think would be convenient for anyone watching > it. then it's a misuse of object manager by the application, not a problem with the spec. We need to define in the API where the object manager(s) will be and not randomly adding/removing them. Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
