Summary of the fdo disussion at GCDS
Michael Leupold
lemma at confuego.org
Thu Jul 9 07:33:52 PDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Simon McVittie wrote:
> On Wed, 08 Jul 2009 at 22:00:09 +0200, Olivier Goffart wrote:
>> We agreed that freedesktop would have a wiki page listing the
>> specification/implementations and saying whether they are blessed by each
>> desktop, and the implementation status.
>>
>> It is not allowed to take namespace on org.freedesktop unless the project
>> get blessed by at least GNOME and KDE.
>
> I think freedesktop.org hosts two types of project, and it's not
> necessarily useful to conflate how they are treated. (I use "project"
> quite loosely here - specification, implementation, whatever.)
>
> On one hand, there are projects that identify themselves solely as
> "freedesktop" or "XDG" standards, like XDG_DATA_DIRS,
> org.freedesktop.Notifications and the still-hypothetical
> org.freedesktop.ScreenSaver. These only have value if they're agreed on
> in a cross-desktop way, so being strict about acceptance seems entirely
> appropriate.
As I understand it freedesktop.org is meant as a place to store shared
specifications. So far it seems adoption of those specifications is what
makes some of them "de-facto standards".
In the current discussion I see two issues which I consider separate mingled
up: Specifications and the org.freedesktop D-BUS namespace. I'd like to
discuss both of them separately:
1. What does it take to make a specification "freedesktop.org"?
Isn't it enough if 2 free desktops accept/bless or implement a specification
so it gets eligible to be published on freedesktop.org? Of course
adoption/acceptance should be visible and it should be clearly stated that a
specification doesn't become a standard by labeling it "freedesktop.org".
Does that mean fd.o would get flooded with a lot of minor, possibly
competing specifications? I don't really think that will be the case. And
even if the volume of specifications grows they would still be categorized
by spread of use - just like the Specifications wiki-page already does.
In the end even having specifications only used by 2 desktops X and Y might
benefit the cross-desktop idea. If the developers of desktop Z are planning
a similar feature they'll see what's available and will be able to implement
the spec as-is, help improving it or co-create a new spec.
As such I'd like to rather see freedesktop.org as a database of
specifications and a place to collaboratively develop new specifications
than as a quasi-standardization institute we have to create a ratification
process for.
2. What's the process of getting a specification up?
I generally like the process that Olivier mentions has been talked about at
the GCDS though there are some details left for discussion. I propose to
generated a "recommended process" with details on where to send calls for
participation to and how to get started.
3. How are names inside the org.freedesktop D-BUS namespace granted?
This question seems to be a lot more complicated. I think new specifications
should live in a sub-namespace and have a non-generic part in their name
(eg. org.freedesktop.<incubator-sub-namespace>.GalagoNotification instead of
org.freedesktop.<incubator-sub-namespace>.Notification). Names in this sub-
namespace should be free for every specification on fd.o to pick but should
be announced somewhere to avoid clashes. Common sense and the will to
cooperate should rule out unacceptable grabbing and hoarding of names.
If a specification is decided to be "generally/widely adopted" (plenty of
discussion on that already) it should be granted a name in the main fd.o
namespace. As mentioned elsewhere objects can be made accessible with the
old as well as the new name.
I'm not sure if we have to think about what to do if a spec with such an
"assigned name" gets forked, do we?
Regards,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFKVf/TlfpzINIAlVsRAvN+AJ0SlDFjdv0E5A083OVbJVssPuBt1gCePDiV
QIdsegLX1RvAkM+sAiNko/4=
=e+wy
-----END PGP SIGNATURE-----
More information about the xdg
mailing list