Summary of the fdo disussion at GCDS
Aaron J. Seigo
aseigo at kde.org
Wed Jul 8 15:54:22 PDT 2009
On Wednesday 08 July 2009, Simon McVittie wrote:
> On the other hand, there are projects that have their own identity, and
> could reasonably continue even if one desktop rejects them - for instance,
> Telepathy, GStreamer, Cairo, Nepomuk, Galago and even D-Bus could all be
> useful projects even if not everyone accepts them, and they all have a
> non-generic "brand name" of their own (which gives them a namespace).
correct; and for something like Cairo there's no shared namespace to really
worry about, just libraries to talk to. in that case a simple descriptive
design spec suffices from beginning to end.
things like Telepathy which are both an implementation _and_ a shared API/file
format/d-bus service spec are a little different, as you note:
> Requiring cross-desktop agreement for an org.freedesktop.ScreenSaver
> interface is all very well, but I think if we'd needed "buy-in" from all
> of time, both in specification and implementation work, to get Telepathy to
> the point where it's actually useful to GNOME or KDE.
these are completely valid points, imo. however:
> Or, is the idea that Telepathy should have "incubated" in some other
> namespace - in practice, that probably means either a "forge" like sf.net,
> a domain name owned by an involved company like Nokia or Collabora, or a
> domain name owned by an interested project like GNOME - and moved to
> freedesktop.org only when it was good enough to get GNOME and KDE approval?
unless both GNOME and KDE signed on to it right away. there's nothing that
says the projects couldn't come together and say, "we like this idea, let's
commit to it early".
this is a nice motivation for projects such as telepathy to work with both
projects from the start, in fact.
the incubation phase is what i'm doing with the system tray d-bus spec, and in
that case it works just fine.
and of course, if both GNOME and KDE were using org.foo.telepathy we could all
move to whatever the new name was and keeping backwards compat is trivial:
* you can register both the old and the new name (org.foo.bar and
org.freedesktop.bar) on d-bus (this is already common place, actually:
org.freedesktop.ScreenSaver also points to some krunner dbus objects, not just
the screen saver ones, but that's an implementation quirk that harms neither
org.freedesktop.ScreenSaver nor krunner)
* applications can check which name is used
the first option is a better way to go, as it's a small change in one place.
eventually the old name can be dropped altogether.
> I think org.freedesktop.Galago.Notifications would have been a much better
> name for notification-daemon's API
ignoring that Galago is an implementation detail in this case (so appearing in
the public name is a bit odd, but certainly defensible), it still says "this
is a freedesktop.org service".
unless we say that only "top level" names are official (e.g.
org.freedesktop.Notifications vs org.freedesktop.foobar.Notifications), in
which case we're right back to where we started (can't tell official apart
from unofficial) and/or we still have to break things to move from
org.freedesktop.foobar.Notifications to org.freedesktop.Notifications.
it's sort of a non-solution, imho, that just reshuffles the chairs on the
deck. the ship would still be sinking ;)
it's important for the proper design of the platform as well as the
depoliticization of which technologies to select to be able to clearly
identify what is and what isn't part of the platform. (currently we create
non-cooperative races to the imaginary finish lines, among other deficiencies)
it's also critical for 3rd party developers to figure out our mess ;)
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090708/7e7b1d1d/attachment.pgp
More information about the xdg