wayland implementation conformance

Kristian Høgsberg krh at bitplanet.net
Wed Jan 26 11:44:19 PST 2011

2011/1/26 Casey Dahlin <cdahlin at redhat.com>:
> On Wed, Jan 26, 2011 at 01:40:25PM -0500, Kristian Høgsberg wrote:
>> 2011/1/26 Josh Leverette <coder543 at gmail.com>:
>> > I'm not certain, but I think there could eventually be enough variation for that to be needed. However, even if there isn't, parsing an XML file might be a better long term solution that weakly linked functions and things like that. Perhaps we could modify his idea about an XML profile structure to allow you to delve into each supported profile and find out more about what it supports without having to hard code acceptable version numbers into a program. The only problem I foresee is how to modify the XML file. It's not going to be the end user's job.. but if any program could modify it there needs to be a fallback system to prevent a rogue program from deleting other profile advertisements written in by the system or other programs.
>> The XML file isn't used at runtime.  It's just a convenient mechanism
>> to describe the interface.  The way it works is that a client connects
>> to the server and the server will then advertise all the global
>> objects available by giving their object id, interface name and
>> version.  A client can then look through the list to see what's
>> available and adjust its behaviour accordingly.
>> Kristian
> Does the XML file have a particular schema?
> It might be useful to install it in /usr/share so it could be used by
> tools. I'm thinking mostly of a d-feet style introspection tool for the
> Wayland protocol (we could even go as far as dynamically adaptable
> bindings for languages like Ruby or Python).

I didn't actually write a schema for it, but if somebody with the
right XML-fu could do that that would be nice.  It's a good point that
dynamic languages probably just want to parse the XML directly and
generate the bindings on the fly and for that we would need to install
the XML.  As for introspection/logging/xscope, that's built into the
server side library: set WAYLAND_DEBUG=1 and watch the requests and
events fly by.


More information about the wayland-devel mailing list