RequestName default flags

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

RequestName default flags

Havoc Pennington
Hi,

For current situation, see:

http://dbus.freedesktop.org/doc/api/html/group__DBusBus.html#ga5

http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-names


I'm not really convinced that the current set of behaviors is right, or
that the defaults are right.

Which flags are people using and for which use-cases? Ideally we can get
a lot of followups describing different ways to use D-BUS names and the
flags people are wanting for them.

It feels to me like the policy for name behavior is in the wrong place,
since it ends up being hardcoded in both client and server; feels like
the .service file would make more sense.

Possibly something to fix for 1.0.

Havoc


--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus
Reply | Threaded
Open this post in threaded view
|

Re: RequestName default flags

Waldo Bastian
For the KDE bindings I think I should be using
DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT in order to get DCOP compatible behavior.

The description for DBUS_REQUEST_NAME_REPLY_IN_QUEUE on  
http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-names is
wrong btw, it says

"The name already had an owner, DBUS_NAME_FLAG_REPLACE_EXISTING was not
specified, and the current owner specified
DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT."

but it should say

"The name already had an owner, DBUS_NAME_FLAG_REPLACE_EXISTING was  
specified, and the current owner specified
DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT."

Would it be possible to allow a dash '-' in busnames btw?

Cheers,
Waldo

On Tuesday 02 August 2005 23:05, Havoc Pennington wrote:

> Hi,
>
> For current situation, see:
>
> http://dbus.freedesktop.org/doc/api/html/group__DBusBus.html#ga5
>
> http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-names
>
>
> I'm not really convinced that the current set of behaviors is right, or
> that the defaults are right.
>
> Which flags are people using and for which use-cases? Ideally we can get
> a lot of followups describing different ways to use D-BUS names and the
> flags people are wanting for them.
>
> It feels to me like the policy for name behavior is in the wrong place,
> since it ends up being hardcoded in both client and server; feels like
> the .service file would make more sense.
>
> Possibly something to fix for 1.0.
>
> Havoc

--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RequestName default flags

Havoc Pennington
On Wed, 2005-08-03 at 00:02 +0200, Waldo Bastian wrote:
> For the KDE bindings I think I should be using
> DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT in order to get DCOP compatible behavior.
>

Right, which seems like a better default...

> The description for DBUS_REQUEST_NAME_REPLY_IN_QUEUE on  
> http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-names is
> wrong btw, it says
>
> "The name already had an owner, DBUS_NAME_FLAG_REPLACE_EXISTING was not
> specified, and the current owner specified
> DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT."
>
> but it should say
>
> "The name already had an owner, DBUS_NAME_FLAG_REPLACE_EXISTING was  
> specified, and the current owner specified
> DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT."
>

Yikes. This is clearly all too confusing.

> Would it be possible to allow a dash '-' in busnames btw?

Sure, right now all the names are very restrictive in allowed
characters, I was trying to make names be valid identifiers in pretty
much every programming language.

Probably no reason to do this for bus names though, only for
methods/interfaces. I only did it for bus names so we could make things
simple and say "rules for bus names are the same as rules for everything
else"

So should the restrictions be, "same rules as interfaces but you can
have hyphen" or ... ?

Havoc


--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus
Reply | Threaded
Open this post in threaded view
|

Re: RequestName default flags

Havoc Pennington
In reply to this post by Havoc Pennington
Hi,

Since only Waldo seems to be following up ;-) what about this proposal:

 - default is PROHIBIT_REPLACEMENT, new optional flag is
   ALLOW_REPLACEMENT

 - default regardless of PROHIBIT vs. ALLOW_REPLACEMENT is to
   queue up to own the name later and return IN_QUEUE

 - flag DO_NOT_QUEUE will cause an error rather than IN_QUEUE
   if name is already owned

 - flag REPLACE_EXISTING will cause replace current owner if
   ALLOW_REPLACEMENT is set, and if PROHIBIT_REPLACEMENT is
   set will return an error or add to queue depending on the
   DO_NOT_QUEUE flag

But ignoring here whether we should move the flags to the .service file.
With this proposal maybe there's no need to... don't know.

Havoc

   

--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus
Reply | Threaded
Open this post in threaded view
|

Re: RequestName default flags

Kalle Vahlman
On 8/3/05, Havoc Pennington <[hidden email]> wrote:
> Hi,
>
> Since only Waldo seems to be following up ;-) what about this proposal:

I was about to, but got caught up in work and forgot and...
 
>  - default is PROHIBIT_REPLACEMENT, new optional flag is
>    ALLOW_REPLACEMENT

Was about suggest this way, since I'd think any service provider wants
to stay as owner more often than not.

If you allow replacement by default, any accidental launching of an
service provider could force clients to reset, if the service is
state-dependant.

Scenario:
Launch IM client, a status applet finds the service and queries status
(of buddies). Launch it again, the applet gets NameOwnerChanged and
has to query again. And again, when the accidentally opened client is
closed.

This could be even worse with multiple service providers kicking each other.

>  - default regardless of PROHIBIT vs. ALLOW_REPLACEMENT is to
>    queue up to own the name later and return IN_QUEUE

Sounds logical to default to second-best option.

>  - flag DO_NOT_QUEUE will cause an error rather than IN_QUEUE
>    if name is already owned

Also is logical, as it is specifically requested not to queue.

>  - flag REPLACE_EXISTING will cause replace current owner if
>    ALLOW_REPLACEMENT is set, and if PROHIBIT_REPLACEMENT is
>    set will return an error or add to queue depending on the
>    DO_NOT_QUEUE flag

Sounds like a plan to me.
 
> But ignoring here whether we should move the flags to the .service file.
> With this proposal maybe there's no need to... don't know.

Unless it's overridable from code, no. You might want to alter the
behaviour based on runtime environment. OTOH, setting the default in
.service would be a nice reference point for 3rd parties to look up if
they can replace a service without digging in the code. I guess I'm
saying "both" :)

--
Kalle Vahlman, [hidden email]
--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus
Reply | Threaded
Open this post in threaded view
|

Re: RequestName default flags

Colin Walters
In reply to this post by Havoc Pennington
On Wed, 2005-08-03 at 12:06 -0400, Havoc Pennington wrote:
> Hi,
>
> Since only Waldo seems to be following up ;-) what about this proposal:
>
>  - default is PROHIBIT_REPLACEMENT, new optional flag is
>    ALLOW_REPLACEMENT

This all makes sense to me.  Every app I've written uses
PROHIBIT_REPLACEMENT to get the unique-app effect.

> But ignoring here whether we should move the flags to the .service file.
> With this proposal maybe there's no need to... don't know.

Hmm...maybe it is a bit cleaner.  If someone writes the patch it should
go in, but if not then everyone just passes an extra 0 to the
RequestName call, not the end of the world.


--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RequestName default flags

Waldo Bastian
In reply to this post by Havoc Pennington
On Wednesday 03 August 2005 06:38, Havoc Pennington wrote:

> On Wed, 2005-08-03 at 00:02 +0200, Waldo Bastian wrote:
> > For the KDE bindings I think I should be using
> > DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT in order to get DCOP compatible
> > behavior.
>
> Right, which seems like a better default...
>
> > The description for DBUS_REQUEST_NAME_REPLY_IN_QUEUE on
> > http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-names
> > is wrong btw, it says
> >
> > "The name already had an owner, DBUS_NAME_FLAG_REPLACE_EXISTING was not
> > specified, and the current owner specified
> > DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT."
> >
> > but it should say
> >
> > "The name already had an owner, DBUS_NAME_FLAG_REPLACE_EXISTING was
> > specified, and the current owner specified
> > DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT."
>
> Yikes. This is clearly all too confusing.
>
> > Would it be possible to allow a dash '-' in busnames btw?
>
> Sure, right now all the names are very restrictive in allowed
> characters, I was trying to make names be valid identifiers in pretty
> much every programming language.
>
> Probably no reason to do this for bus names though, only for
> methods/interfaces. I only did it for bus names so we could make things
> simple and say "rules for bus names are the same as rules for everything
> else"
>
> So should the restrictions be, "same rules as interfaces but you can
> have hyphen" or ... ?
I think it is more clear to spell it out. While I was at it, I also added some
text to explain "unique connection names" a bit more. See patch. Did I get
that right?

Cheers,
Waldo

--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus

dbus-specification.diff (4K) Download Attachment
attachment1 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RequestName default flags

Havoc Pennington
On Fri, 2005-08-05 at 18:35 +0200, Waldo Bastian wrote:
>
> I think it is more clear to spell it out. While I was at it, I also added some
> text to explain "unique connection names" a bit more. See patch. Did I get
> that right?

Patch looks quite good to me. There's also a code patch needed to
dbus-marshal-validate.c:_dbus_validate_bus_name() of course.

Havoc


--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus
Reply | Threaded
Open this post in threaded view
|

Re: RequestName default flags

Waldo Bastian
On Friday 05 August 2005 21:01, Havoc Pennington wrote:
> On Fri, 2005-08-05 at 18:35 +0200, Waldo Bastian wrote:
> > I think it is more clear to spell it out. While I was at it, I also added
> > some text to explain "unique connection names" a bit more. See patch. Did
> > I get that right?
>
> Patch looks quite good to me. There's also a code patch needed to
> dbus-marshal-validate.c:_dbus_validate_bus_name() of course.

I basically folded _dbus_validate_unique_name and _dbus_validate_interface
into _dbus_validate_bus_name and then replaced
VALID_NAME_CHARACTER with VALID_BUS_NAME_CHARACTER.

The diff represents that change a bit weird since it matches parts of the old
_dbus_validate_unique_name with the new _dbus_validate_bus_name.

Cheers,
Waldo

--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus

dbus_busname.diff (6K) Download Attachment
attachment1 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RequestName default flags

Havoc Pennington
On Tue, 2005-08-09 at 22:56 +0200, Waldo Bastian wrote:

> On Friday 05 August 2005 21:01, Havoc Pennington wrote:
> > On Fri, 2005-08-05 at 18:35 +0200, Waldo Bastian wrote:
> > > I think it is more clear to spell it out. While I was at it, I also added
> > > some text to explain "unique connection names" a bit more. See patch. Did
> > > I get that right?
> >
> > Patch looks quite good to me. There's also a code patch needed to
> > dbus-marshal-validate.c:_dbus_validate_bus_name() of course.
>
> I basically folded _dbus_validate_unique_name and _dbus_validate_interface
> into _dbus_validate_bus_name and then replaced
> VALID_NAME_CHARACTER with VALID_BUS_NAME_CHARACTER.
>
> The diff represents that change a bit weird since it matches parts of the old
> _dbus_validate_unique_name with the new _dbus_validate_bus_name.
>

This looks great, thanks. It's fine to commit this and the spec change.
It would be good to also add a few more test cases to
dbus-marshal-validate-util.c to reflect this change (test dcop-like
names) and maybe try to trigger all of the codepaths in the new
function. It should be really easy to do, the existing code already has
arrays of valid and invalid stuff and then runs the validation functions
on the arrays.
You might have to add a new array for bus names since right now it uses
the interface name tests to also test validate_bus_name().

Havoc


--
dbus mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/dbus