On 17/07/15 00:13, Dan Williams wrote:
> eg, think of it as each contact in Telepathy being an object
Telepathy contacts aren't "real D-Bus objects", for precisely this reason.
Telepathy does a lot of batching information into one method call; some
of it is basically a precursor of the ObjectManager interface, and some
of it (contacts and their attributes) is more specialized. The initial
motivating use-case was that batching the "get contact's name" method
call into (effectively) "get n contacts' names" made it orders of
magnitude faster to join a busy IRC channel like #ubuntu. Recent-ish
Telepathy can also batch arbitrarily many attributes of contacts into
one method call, with a filtering mechanism so you don't have to get the
attributes you don't care about.
If Telepathy didn't already exist and I had to invent it now, I'd mostly
be using ObjectManager. Contacts would probably be strings, because
practicality beats purity, and some uses of Telepathy (like joining
#ubuntu) involve a silly number of contacts; or they might be
object-paths that in practice you mainly use as opaque tokens in
array-based APIs, and rarely or never actually call methods on.
> Also, how is a client supposed to know how big the limit is? Or is a
> client just supposed to use a sufficiently low number that it is known
> to work in all cases?
My usual rule of thumb is that if you have a finite number of orthogonal
method calls ("get name", "get icon", "get hat colour") you can probably
get away with parallelizing them, but if you have an potentially
unbounded number of method calls ("get Dan's icon", "get Michael's
icon", ...) you should delay each one until the previous one finished.
Note that the system bus has a much lower limit than the session bus,
because if you carry out a DoS attack on the session bus you're only
hurting yourself, whereas a DoS attack on the system bus hurts system
services and other users. (Not true in kdbus-land, though, because
kernel resources; I think kdbus imposes the same lower limit on user buses.)
> The solution here is likely to transition the libnm implementation over
> to the ObjectManager interface's GetManagedObjects() method for the
> initial setup, to get everything in one call. A lot of data, but likely
> faster than doing it piece-by-piece.
That's what I'd recommend; ObjectManager is precisely for situations
where clients are interested in "most" children of a parent object.
> Any
> chance we could get dbus-glib to implement GetManagedObjects()?
It is entirely possible to "roll your own" GetManagedObjects; indeed,
Telepathy reimplements the entire service-side Properties interface
(because dbus-glib was historically even worse than it is now).
I'm a little reluctant to add features to dbus-glib, because it's a dead
end; but if it helps NM, I'd make an exception for reviewing
ObjectManager support.
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
