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@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel