Unity For Fedora (As in OpenSUSE or Arch)

Matthew Garrett mjg59 at srcf.ucam.org
Thu Feb 2 01:02:32 UTC 2012


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 at srcf.ucam.org


More information about the devel mailing list