On Thu, Feb 02, 2012 at 08:19:44PM +0100, Kevin Kofler wrote: > Matthew Garrett wrote: > > The answer still resulted in a spec that permitted compliant > > implementations to have no practical interoperability. > > You keep repeating that, yet I still don't see ANYTHING backing that > assertion. Interoperability depends only on the protocol (which is clearly > specified), not on the visualization (which is not). Ok. I can't guarantee that an OverlayIcon will be rendered. So since I can't rely on it, I can never use it to provide important information. And since the point of this specification is to provide information to the user, that means that the OverlayIconName field is effectively useless. If I do render an OverlayIconName and also pass a window ID, it's valid for clicking the icon to raise my application - but it's also valid for it to destroy my window and kill my connection to the server. I'm willing to bet actual, real money that there are applications currently using this specification that would be massively unusable under perfectly compliant implementations of this specification. But rather than have that discussion, the spec proposers simply asserted that the complete absence of any behavioural guarantees regarding visualisation was a feature. That's a pretty fundamental disagreement, and if that disagreement can't be overcome then you can't expect the spec to be adopted. > > You can't force people to adopt a spec if they think it's a bad spec. > > Not always true. See e.g. Samba. Samba is a project written specifically to interoperate with Windows, because the developers involved felt that interoperability was more important than the flaws in the SMB spec (to the extent that any such thing existed). Nobody forced them to do that. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel