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