On Thu, Feb 02, 2012 at 01:51:55AM +0100, Kevin Kofler wrote:
Matthew Garrett wrote:
> I'm on multiple spec bodies. If someone proposed an ammendment that
> allowed two conforming implementations to be entirely incompatible, and
> then argued that this was future proofing, they'd be laughed at.
The constraints actually relevant for compatibility are all specified very
clearly! E.g., there are some D-Bus methods, there is a string which takes
an icon name etc. Your implementation can look entirely different (that's
the point!), but it will still be COMPATIBLE.
It can be completely unusable. There's no way to design an application
that will work with all valid implementations.
> The purpose of a spec is to *ensure* interoperability between
different
> implementations. Any spec that relies on common sense is a bad spec.
So you WOULD specify the value of pi in your spec?! ^^
No, because it's adequately specified elsewhere. A correct
implementation of this spec isn't.
And the spec as is DOES ensure interoperability. It does not ensure
visual
uniformity, by design. (Neither does the message-based notification spec
GNOME implements and recommends, by the way. The GNOME 3 message tray, the
Plasma notifier and the more traditional passive popup implementations used
elsewhere all implement the notification spec, yet look VERY different.)
Yes, but it's not about visual uniformity. It's about ensuring that
information is presented.
And finally, even if the spec really were as badly written as you
claim, it
would still be very much possible to interoperate with the actual
implementations. Samba was written without any spec at all, and unlike Samba
you even have the source code of the applications and workspaces you'd
interoperate with. So the quality of the spec is a very poor argument for
not being interoperable.
If the point is interoperability then just propose a version of the spec
that actually guarantees useful interoperability.
--
Matthew Garrett | mjg59(a)srcf.ucam.org