<div dir="ltr">On Fri, Jan 3, 2014 at 5:18 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:mzqohf@0pointer.de" target="_blank">mzqohf@0pointer.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> I believe the no-flags (flags=0) case is supposed to be sensible defaults<br>
> and the flags are supposed to be the thing you'd opt into because you know<br>
> what you are doing. There may even be discussion in the archives about<br>
> flipping them for this reason, I don't know.<br>
<br>
</div>That would certainly make sense, howver doesn't appear to  be the<br>
case. For example, when acquiring a name this would suggest that<br>
queuing for a name would be the best default. However, I am quite sure<br>
that most daemons probably want to know early if the name is already<br>
taken, and I think most daemons hence currently don't pass a 0 flag when<br>
acuiring their name...<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Yes, some of the flags may have wrong defaults. You now have the advantage of actual data on dbus usage (which was not the case when picking these flags).<br>

<br></div><div>Queuing is intended for a service name which might be provided by multiple things, where the things might watch for whether they now own the name but aren't going to exit if they don't own it.<br><br>

</div><div>You're probably right that isn't the common case.<br><br></div><div>It probably makes sense to fix the defaults but I just wanted to point out that there was supposed to be a rationale for the "direction" of these flags.<br>

</div><div><br>Havoc<br><br></div><div><br></div></div></div></div>