2011/1/26 Josh Leverette <[email protected]>: > 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 <[email protected]> wrote: > >> On Wed, Jan 26, 2011 at 12:15 PM, Marcus Lorentzon >> <[email protected]> wrote: >>> On 01/26/2011 03:57 PM, Kristian Høgsberg wrote: >>>> >>>> On Wed, Jan 26, 2011 at 8:22 AM, Tiago Vignatti >>>> <[email protected]> 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 >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
