wayland implementation conformance

[Marcus Lorentzon]

On 01/26/2011 03:57 PM, Kristian Høgsberg wrote:
> On Wed, Jan 26, 2011 at 8:22 AM, Tiago Vignatti
> <tiago.vignatti at nokia.com>  wrote:
>    
>> Hi,
>>
>> I hijacked this comment which Kristian made in the other email thread; my
>> comments are inline.
>>
>> On 01/24/2011 09:30 PM, ext Kristian Høgsberg wrote:
>>      
>>> Once of the things that X got right was the extension model.  Wayland
>>> takes it one step further by making everything an extension: the only
>>> thing that's fixed in the Wayland protocol is an interface for
>>> discovering other interfaces.  If it turns out that we need to update
>>> the input model, we have versioning built in for incremental updates,
>>> and we can add an entire new model if we need to start from scratch.
>>>        
>> So what defines exactly a Wayland implementation which is conformant with
>> the protocol then?
>>
>> Let's say I don't care about drm_interface and my implementation works okay
>> without it. Does my software is called Wayland then? Nevertheless, in this
>> case, I won't be able to connect the same clients from such implementation
>> on some other Wayland server that relies on DRM. So if we target
>> interoperability between clients and server, then I guess we will want to
>> define hardly a few interfaces.
>>      
> That's a good question.  My intention is to have wayland.xml be the
> official interfaces, but you're right that the drm interface is
> specific to the Linux drm driver model and maybe that should be split
> out into its own file.  Additionally, it would make sense to abstract
> out the wl_buffer creation into a library that server and client can
> link to so that not every toolkit and application that use the wayland
> protocol directly will have to know about every driver specific
> interface for creating and sharing buffers.
>    

What about adding "profiles" or interface groups in the protocol xml. 
Client could query compositor of a list of profiles supported. And 
profiles could be hierarchical like:

base (very basic profile allowing simple surfaces and input)
desktop/netbook : base (base + d&d, mouse pointer, multi touch etc)
kde/gnome : desktop (desktop + shell interfaces)
pad/phone : base (base + multi touch, overlays, orientation, ...)
meego : phone (phone + meego shell services)
...

A sample ubuntu profile list could be "base 2.3;desktop 1.2;pad 
1.3;gnome 1.1;ubuntu 2.0"

That would make it easier for apps to target specific platforms, create 
better fallbacks and improve device/platform portability/interop.

/BR
/Marcus