|
"default" object path
Hi,
Random thought; this may have some up before, but a in a lot of cases
(system service, desktop app) there tends to be one "manager" object
which is the primary interface to the app.
People have complained about the verbosity of dbus-send before, and
they're not really wrong. What if we added a flag in the
introspection XML (say) that denoted an object path as "primary"?
Bindings could expose this in some way; I could imagine a manual API
like gdbus_export_primary_object (const char *opath); for desktop apps
it could be done automatically for GApp/QApp type classes.
Then if you did say:
dbus-send --print-reply org.freedesktop.DBus.ListNames
It would could assume service name == interface name, grab the
introspection XML, find that the path /org/freedesktop/DBus is tagged
as primary and implements org.freedesktop.DBus. Or maybe it could be:
dbus-send --print-reply org.freedesktop.DBus ListNames
Where the subtle distinction here is that we take org.freedesktop.DBus
as the service name, and grab the first primary object that has a
method "ListNames".
Thoughts?
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
On Fri, 2009-10-16 at 19:28 +0000, Colin Walters wrote:
> Hi,
>
> Random thought; this may have some up before, but a in a lot of cases
> (system service, desktop app) there tends to be one "manager" object
> which is the primary interface to the app.
>
> People have complained about the verbosity of dbus-send before, and
> they're not really wrong.
We have bash-completion support in dbus-send [1]. It solves all of these
problems. IOW, let's not add features to the protocol / spec when we can
just as easily fix the tools.
David
[1] : Admittedly it broke with bash 4.0 but that's a bug we need to fix
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
On Fri, Oct 16, 2009 at 8:02 PM, David Zeuthen < david@...> wrote:
>
> We have bash-completion support in dbus-send [1]. It solves all of these
> problems. IOW, let's not add features to the protocol / spec when we can
> just as easily fix the tools.
That helps, I agree, but it's not quite the same thing; I could
imagine the concept of the "default" object being useful for scripts
and bindings, not just interactive sessions.
For example, it'd be nice if you knew that in a script:
dbus-send --print-reply org.freedesktop.DBus ListNames
would continue to do the same thing even in the face of possible new
interfaces on the bus (as is being discussed), etc.
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
>On Fri, Oct 16, 2009 at 8:02 PM, David Zeuthen < david@...> wrote:
>> We have bash-completion support in dbus-send [1]. It solves all of these
>> problems. IOW, let's not add features to the protocol / spec when we can
>> just as easily fix the tools.
>
>That helps, I agree, but it's not quite the same thing; I could
>imagine the concept of the "default" object being useful for scripts
>and bindings, not just interactive sessions.
Also, believe it or not, some people use tcsh, etc, or have to use it on
an embedded device with busybox.
The script point is a good one, though such "auto" behavior is something
you want to be careful with if it generates a lot of extra dbus traffic
to resolve the object/method, especially in scripts. This should be
discussed/mentioned in the man page/help/etc.
--
Randell Jesup, Worldgate (developers of the Ojo videophone)
rjesup@...
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
On Fri, 2009-10-16 at 20:25 +0000, Colin Walters wrote:
> On Fri, Oct 16, 2009 at 8:02 PM, David Zeuthen < david@...> wrote:
> >
> > We have bash-completion support in dbus-send [1]. It solves all of these
> > problems. IOW, let's not add features to the protocol / spec when we can
> > just as easily fix the tools.
>
> That helps, I agree, but it's not quite the same thing; I could
> imagine the concept of the "default" object being useful for scripts
> and bindings, not just interactive sessions.
>
> For example, it'd be nice if you knew that in a script:
>
> dbus-send --print-reply org.freedesktop.DBus ListNames
>
> would continue to do the same thing even in the face of possible new
> interfaces on the bus (as is being discussed), etc.
For non-interactive use you are supposed to be adhering to the API
contract which should state exactly what the well-known path of (one or
more) objects is. Do you have anything more specific than "scripts and
bindings" in mind?
I think adding something like this is really a slippery slope - if we
add this some people use this feature instead of adhering to the API
contract and then they can run into unintended consequences if another
"default object" is suddenly added.
Now, it's true that most services don't really makes it easy to figure
out what the API contract is and, sure, this feature would help
alleviate that problem. But I think it would be better to just beat such
people with a stick and make them document their APIs. Writing better
tools to e.g. generate Docbook/HTML/whatever from IDL/Introspection XML
is a step in this direction (see e.g. eggdbus-binding-tool(1)). Giving
such people a free ride is a step back. </tangential-paragraph>
David
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
Em Sexta-feira 16. Outubro 2009, às 22.02.32, David Zeuthen escreveu:
> On Fri, 2009-10-16 at 19:28 +0000, Colin Walters wrote:
> > Hi,
> >
> > Random thought; this may have some up before, but a in a lot of cases
> > (system service, desktop app) there tends to be one "manager" object
> > which is the primary interface to the app.
> >
> > People have complained about the verbosity of dbus-send before, and
> > they're not really wrong.
>
> We have bash-completion support in dbus-send [1]. It solves all of these
> problems. IOW, let's not add features to the protocol / spec when we can
> just as easily fix the tools.
>
> David
>
> [1] : Admittedly it broke with bash 4.0 but that's a bug we need to fix
Make / the default object. Easy to type, even on busybox on an embedded
device.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14 San Francisco, California: Nov 2 - 4
http://qt.nokia.com/qtdevdays2009 _______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
On Fri, 16.10.09 23:18, Thiago Macieira ( thiago@...) wrote:
> Em Sexta-feira 16. Outubro 2009, às 22.02.32, David Zeuthen escreveu:
> > On Fri, 2009-10-16 at 19:28 +0000, Colin Walters wrote:
> > > Hi,
> > >
> > > Random thought; this may have some up before, but a in a lot of cases
> > > (system service, desktop app) there tends to be one "manager" object
> > > which is the primary interface to the app.
> > >
> > > People have complained about the verbosity of dbus-send before, and
> > > they're not really wrong.
> >
> > We have bash-completion support in dbus-send [1]. It solves all of these
> > problems. IOW, let's not add features to the protocol / spec when we can
> > just as easily fix the tools.
> >
> > David
> >
> > [1] : Admittedly it broke with bash 4.0 but that's a bug we need to fix
>
> Make / the default object. Easy to type, even on busybox on an embedded
> device.
Oh. no! That would be wrong. The / path should *not* be used for anything.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
|
|
Re: "default" object path
Em Sexta-feira 16. Outubro 2009, às 23.27.52, você escreveu:
> On Fri, 2009-10-16 at 23:18 +0200, Thiago Macieira wrote:
> > Make / the default object. Easy to type, even on busybox on an embedded
> > device.
>
> No, that's really bad advice, the object path name space is essentially
> system-wide. See this blog entry (and comments) for specific details on
> why this won't work in general:
>
> http://0pointer.de/blog/projects/versioning-dbus.htmlThere are no arguments against placing many interfaces in the same object in
that link.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14 San Francisco, California: Nov 2 - 4
http://qt.nokia.com/qtdevdays2009 _______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
Em Sexta-feira 16. Outubro 2009, às 23.22.47, Lennart Poettering escreveu:
> Oh. no! That would be wrong. The / path should *not* be used for anything.
Why not? It's an object path like any other. And it's the easiest one to type.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14 San Francisco, California: Nov 2 - 4
http://qt.nokia.com/qtdevdays2009 _______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
On Fri, 2009-10-16 at 23:57 +0200, Thiago Macieira wrote:
> Em Sexta-feira 16. Outubro 2009, às 23.27.52, você escreveu:
> > On Fri, 2009-10-16 at 23:18 +0200, Thiago Macieira wrote:
> > > Make / the default object. Easy to type, even on busybox on an embedded
> > > device.
> >
> > No, that's really bad advice, the object path name space is essentially
> > system-wide. See this blog entry (and comments) for specific details on
> > why this won't work in general:
> >
> > http://0pointer.de/blog/projects/versioning-dbus.html>
> There are no arguments against placing many interfaces in the same object in
> that link.
Several times actually. Let me repeat it the argument then.
Consider two services with names org.Foo and org.Bar both exporting the
"manager" object at /. Suppose both services supports an hypothetical
shared and well-known interface called org.freedesktop.Service. Suppose
this interface has a signal ServiceIsIdle() that lets users know the
service is now idle.
Initially we have two different processes (e.g. different unique bus
names) owning org.Foo and org.Bar. There is no problem, apps can
reliably receive the signal ServiceIsIdle() and life is good.
Suppose now that we have a single unique bus name, say :1.42, owning
both org.Foo and org.Bar. This is perfectly valid and I bet we will see
this happening more in the future as distros consolidate all the system
services. Anyway, now org.Foo emits the ServiceIsIdle() signal. This is
sent to the message bus. The bus rewrites the org.Foo name present in
the header to :1.42.
What happens now?
Well, clients just receive a message saying that the object / owned
by :1.42 emitted the ServiceIsIdle() signal on the org.fd.Service
interface. What clients _don't know_ is that whether it was org.Foo or
org.Bar that emitted the signal. They just can't know.
Hence, putting objects at '/' is a horrible idea.
If you read the archives of this list you will see that people have been
saying this over and over again. Most of the time on the "trust us,
don't do it" level. I hope this is a good technical explanation though.
Thanks,
David
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
Em Sábado 17. Outubro 2009, às 00.42.32, David Zeuthen escreveu:
> On Fri, 2009-10-16 at 23:57 +0200, Thiago Macieira wrote:
> > Em Sexta-feira 16. Outubro 2009, às 23.27.52, você escreveu:
> > > On Fri, 2009-10-16 at 23:18 +0200, Thiago Macieira wrote:
> > > > Make / the default object. Easy to type, even on busybox on an
> > > > embedded device.
> > >
> > > No, that's really bad advice, the object path name space is essentially
> > > system-wide. See this blog entry (and comments) for specific details on
> > > why this won't work in general:
> > >
> > > http://0pointer.de/blog/projects/versioning-dbus.html> >
> > There are no arguments against placing many interfaces in the same object
> > in that link.
>
> Several times actually. Let me repeat it the argument then.
>
> Consider two services with names org.Foo and org.Bar both exporting the
> "manager" object at /. Suppose both services supports an hypothetical
> shared and well-known interface called org.freedesktop.Service. Suppose
> this interface has a signal ServiceIsIdle() that lets users know the
> service is now idle.
>
> Initially we have two different processes (e.g. different unique bus
> names) owning org.Foo and org.Bar. There is no problem, apps can
> reliably receive the signal ServiceIsIdle() and life is good.
>
> Suppose now that we have a single unique bus name, say :1.42, owning
> both org.Foo and org.Bar. This is perfectly valid and I bet we will see
> this happening more in the future as distros consolidate all the system
> services. Anyway, now org.Foo emits the ServiceIsIdle() signal. This is
> sent to the message bus. The bus rewrites the org.Foo name present in
> the header to :1.42.
>
> What happens now?
This is assuming that clients need to know which service it was. I don't see
why they need to. Now the manager object just needs to apply to all objects in
the same connection: i.e. a "ServiceIsIdle" signal would be emitted when both
of the services are idle now.
Besides, you can still differentiate by interface. You're assuming that the
same interface is used by the manager object in both services. If we assume
that, then I'd argue that merging the services into one common manager object
also works just fine.
If they had different interfaces, then nothing changed because you can still
tell which one is which.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14 San Francisco, California: Nov 2 - 4
http://qt.nokia.com/qtdevdays2009 _______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
On Sat, 2009-10-17 at 09:18 +0200, Thiago Macieira wrote:
> This is assuming that clients need to know which service it was. I don't see
> why they need to. Now the manager object just needs to apply to all objects in
> the same connection: i.e. a "ServiceIsIdle" signal would be emitted when both
> of the services are idle now.
>
> Besides, you can still differentiate by interface. You're assuming that the
> same interface is used by the manager object in both services. If we assume
> that, then I'd argue that merging the services into one common manager object
> also works just fine.
>
> If they had different interfaces, then nothing changed because you can still
> tell which one is which.
Both of your suggestions require either breaking the semantics or the
syntax of each service. E.g. ABI breaks. And in some cases it might not
be possible - the signal on the hypothetical org.fd.Service could be in
a form where you just can't consolidate both services into one (consider
a signal ServiceDescriptionChanged(STRING) - where Description is some
human-readable description of the service).
I'm not making this up, btw.
A more realistic example would be a standardized D-Bus interfaces for
the "agent registration" pattern - one example is in polkit with the
RegisterAuthentication() and UnregisterAuthenticationAgent() methods and
the AuthenticationAgent D-Bus interface [1]. Other examples includes the
Bluez stack. It would be *useful* to have a standardized interface for
this so the various toolkit stacks out there (e.g. the G stack, Qt and
so on) could provide helper classes / utility for using it.
Also, people, especially those working on embedded platforms, *are*
going to want to reduce the number of processes running at both the
system- and login-session-level. E.g. it's a bit expensive to have N
daemons for providing N services - it's better to consolidate such
things into a single process (gnome-settings-daemon for example) where
it's appropriate.
Anyway, you are free to keep pretending that it's a good idea to just
register objects at '/'. You just get to keep both pieces when something
breaks ;-)
David
[1] :
http://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.Authority.html#eggdbus-method-org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgenthttp://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.AuthenticationAgent.html>
> _______________________________________________
> dbus mailing list
> dbus@...
> http://lists.freedesktop.org/mailman/listinfo/dbus_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: "default" object path
Em Sábado 17. Outubro 2009, às 20.42.16, David Zeuthen escreveu:
> Anyway, you are free to keep pretending that it's a good idea to just
> register objects at '/'. You just get to keep both pieces when something
> breaks ;-)
I'm not saying / is good for all objects.
What I am saying is the original thread about a "default" object did not have
any reason to not use it.
But that's mostly because the use-case of a "default" object are not very
clear. It needs some clarifying what such an object would do or what it would
be for before we can define where it should be in.
Or we can not do it and simply accept a "fits all" solution. A simple replacing
s,\.,/,g;s,^,/, in the service name would be enough.
In any case, that's a dbus-send feature. Nothing changes in the protocol or
the library.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14 San Francisco, California: Nov 2 - 4
http://qt.nokia.com/qtdevdays2009 _______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Java D-Bus binding for JavaME Profiles
I was wondering if anyone has had any experience compiling and using the Java D-Bus binding in a cell phone's J2ME environment, specifically using either the CLDC or CDC profiles. The docs for the Java D-Bus binding seem to indicate it will compile with a Java 1.5 compiler but provides little or no indication (that I'm aware of) with regards to the minimum Java environment it will support. Can anyone provide this answer?
Thanks . . .
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: Java D-Bus binding for JavaME Profiles
On Mon Oct 19 07:37, Schmottlach, Glenn wrote:
> I was wondering if anyone has had any experience compiling and using
> the Java D-Bus binding in a cell phone's J2ME environment,
> specifically using either the CLDC or CDC profiles. The docs for the
> Java D-Bus binding seem to indicate it will compile with a Java 1.5
> compiler but provides little or no indication (that I'm aware of) with
> regards to the minimum Java environment it will support. Can anyone
> provide this answer?
I don't rely on very much from the Java standard libraries, but I rely
heavily on the introspection APIs. As long as those are complete it
should work fine.
Try compiling the source and run 'make check', that should exercise most
of the code paths.
Matt
--
www.matthew.ath.cx
D-Bus Java
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
RE: Java D-Bus binding for JavaME Profiles
Unfortunately, Java Reflection and Generics did not make it into the CLDC profile.
Are you aware of a reworked version of your binding in Palm's WebOS ( http://palm.cdnetworks.net/opensource/1.1.0/palmipc-java-1.0.0.tgz) It looks like they might have pared it down a little and provided some form of "mini" D-Bus binding that doesn't require reflection. It looks like the lower level core library . . . analogous the the reference D-Bus 'C' library. Perhaps that's fertile ground to explore.
________________________________________
From: Matthew Johnson [ dbus@...]
Sent: Sunday, October 25, 2009 5:36 AM
To: Schmottlach, Glenn
Cc: dbus@...
Subject: Re: Java D-Bus binding for JavaME Profiles
On Mon Oct 19 07:37, Schmottlach, Glenn wrote:
> I was wondering if anyone has had any experience compiling and using
> the Java D-Bus binding in a cell phone's J2ME environment,
> specifically using either the CLDC or CDC profiles. The docs for the
> Java D-Bus binding seem to indicate it will compile with a Java 1.5
> compiler but provides little or no indication (that I'm aware of) with
> regards to the minimum Java environment it will support. Can anyone
> provide this answer?
I don't rely on very much from the Java standard libraries, but I rely
heavily on the introspection APIs. As long as those are complete it
should work fine.
Try compiling the source and run 'make check', that should exercise most
of the code paths.
Matt
--
www.matthew.ath.cx
D-Bus Java
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
|
Re: Java D-Bus binding for JavaME Profiles
On Sun Oct 25 20:16, Schmottlach, Glenn wrote:
> Unfortunately, Java Reflection and Generics did not make it into the CLDC profile.
> Are you aware of a reworked version of your binding in Palm's WebOS
> ( http://palm.cdnetworks.net/opensource/1.1.0/palmipc-java-1.0.0.tgz)
> It looks like they might have pared it down a little and provided some
> form of "mini" D-Bus binding that doesn't require reflection. It
> looks like the lower level core library . . . analogous the the
> reference D-Bus 'C' library. Perhaps that's fertile ground to explore.
Ah, I did not. It does remind me, however, that my bindings do supply a
low-level interface[1]. If you compile on a full JDK and then only use
those parts, it should work, since I use nothing complicated at all.
I don't know what the palmipc folks use, I'll take a look.
1. Here's the example of the low-level API from the dbus-java
documentation:
BusAddress address = new BusAddress(
System.getenv("DBUS_SESSION_BUS_ADDRESS"));
Transport conn = new Transport(address, true);
Message m = new MethodCall("org.freedesktop.DBus", "/org/freedesktop/DBus",
"org.freedesktop. DBus", "Hello", (byte) 0, null);
conn.mout.writeMessage(m);
m = conn.min.readMessage();
System.out.println("Response to Hello is: "+m);
m = new MethodCall("org.freedesktop.DBus", "/org/freedesktop/DBus",
"org.freedesktop.DBus", "RequestName", (byte) 0,
"su", "org.testname", 0);
conn.mout.writeMessage(m);
conn.disconnect();
--
Matthew Johnson
www.matthew.ath.cx
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus
|
signature.asc (197 bytes) 