hp at redhat.com
Mon Sep 4 08:10:43 PDT 2006
Frans Englich wrote:
> I think the wisest thing to do is to turn Free Desktop into a huge whiteboard
> and push the specifications into standard bodies. The latter would indeed be
> part of Free Desktop's mission, in order to ensure that it actually happen,
> instead of them staying on FD's server(such as turning DBus into an RFC).
There are good reasons freedesktop.org is not a standards body; it would
simply be too slow and too much work, and open source developers would
not bother with it. The goal originally was and always has been
pragmatic - the idea isn't "standards" but "people have a place to talk
to each other and see they could share code or an approach."
I think you're right that the way to go if anything really needs
standardizing is to send it through IETF or W3C or X.org or whoever else.
In many cases I have to say I don't see the point, simply because the
only people who care at all are X-based desktop implementors, and
there's no real value to expanding the audience or the number of cooks.
You're right that it involves work and money, and we shouldn't blow
either our own work/money or that of a standards body when it won't have
Where I'd see the point of a formal spec: something that we'd truly
expect to be widely reimplemented.
If you look at freedesktop.org successes, most of them are
implementation standards (cairo, fontconfig, dbus, Xlib) that may happen
to have a spec, but the real win was the shared implementation.
Formal specs usually have long lists of implementations, while
freedesktop generally has 2 or 3 at most, and even in those cases we'd
probably rather have 1.
So one question is which specs are these? Are there any specs that we're
looking to have widely used outside of a short list of known open source
EWMH is the only freedesktop spec I can quickly think of that has a
fairly large number of implementations.
Another argument for formal specs has been ABI/API guarantees, but
personally I think stable ABI comes from good implementation maintenance
and good compatibility testing, I don't think spending a lot of time on
specs does much more than cover asses ("you relied on unspecified
In particular there's a long history of people whining about ABI changes
/ lack of guarantees and proposing various documentation/policy
solutions, when the real problem is just finishing the code such that
it's maintainable and we have something ready to be frozen and widely
used. i.e. usually we need hacking, not specs, on the ABI front -
whether fixing the way things work to be sane enough to freeze, or
coding compatibility tests. IMHO of course.
A final reason I get the sense people like formal specs - they want to
impose a spec top-down when it isn't getting "naturally" adopted. I
think all the core maintainers are pretty against this, and it leads to
deeply broken specs with no relationship to reality.
Again here I think the solution is code, not specs. Take the "font
problem," we could have written specs (and whined about fragmentation)
for years, but just pragmatically writing fontconfig was a better solution.
The same holds for current problems such as the "vfs problem" or "applet
problem" or whatever. Coding work will fix these, specs will not.
More information about the dbus