wayland implementation conformance

[Kristian Høgsberg]

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

> On Jan 26, 2011, at 1:03 PM, Kristian Høgsberg <krh at bitplanet.net> wrote:
>
>> On Wed, Jan 26, 2011 at 12:15 PM, Marcus Lorentzon
>> <marcus.xm.lorentzon at stericsson.com> wrote:
>>> 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.
>>
>> I think of it more as GL extensions or X extensions.  You have to find
>> out whats available at run time and enable, disable or limit
>> functionality according to the interfaces the compositor provides.  Or
>> worst case just refuse to run.  But I don't expect to see as much
>> variation as you suggest in the example above, I think most of the
>> functionality you mention will be in the core set of interfaces and
>> something like "meego shell services" will be something that MeeGo
>> will have to specify.
>>
>> Kristian
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>