Juan, Jonas and Christopher,<div><br></div><div>I appreciate your feedback! Small additions to shells are indeed not a problem. It was not a right example to make my point. As it is now, Weston can be considered barebone since the code base is small. The question is how long it will stay that way, given some interest from Canonical to integrate it into Ubuntu QQ or RR (hopefully QQ) and potentially other distros.</div>

<div><br></div><div>Please, let me give you another example of what I'm trying to do (without going into application specifics that you are unlikely to be interested in).</div><div><br></div><div>Suppose that you want to develop your own Wayland compliant server (W-server) that can render in 3D. Due to renderer's complexity you anticipate that the compositor will grow quite a bit and that will pose significant problems for future testing. </div>

<div><br></div><div>So, before you start out, you want to set up another very simple compositor whose job is _not_ to composite but to _test_ functionality and speed of the graphics driver stack, X as a client, some other hardware, client's compliance to Wayland protocol, and so on. The purpose of such a W-server is to have a regression system that checks dependent _libraries_and_drivers_ rather than your 3D compositor. If something goes wrong with client's rendering (e.g. too slow, visual artifacts) you can use that "regression compositor" to quickly identify if the problem stems from some upgraded or buggy drivers. This will save you a lot of debugging effort and time.<br>

<br>The barebone version of Weston is the perfect candidate for the "regression compositor". It doesn't need several full featured clients or shells to minimize risk of injecting bugs. It only needs to include the minimal architecture plus a set of driver/library test codes. It does need to be relatively stable and up-to-date with the latest Wayland protocol changes and some critical bug fixes though. <br>

<br>I hope the above example illustrates one of several potential applications for the barebone compositor. The point here is not to get rid of useful features from Weston. They are surely needed when I use Weston as a _user_. The above example uses the compositor as a _tester_ with predefined composite screen objects. </div>

<div><br></div><div>Does it make sense or am I making things more complicated than they should be?</div><div>Thanks,</div><div><br>Nick<br><br><br><div class="gmail_quote">On Wed, Jul 11, 2012 at 3:59 AM, Christopher James Halse Rogers <span dir="ltr"><<a href="mailto:christopher.halse.rogers@canonical.com" target="_blank">christopher.halse.rogers@canonical.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, 2012-07-10 at 18:53 -0700, Mikalai Kisialiou wrote:<br>
</div><div><div>> There is an article on <a href="http://www.phoronix.com" target="_blank">http://www.phoronix.com</a> that there is a new<br>
> feature of sliding desktop support in Weston. I am wondering if it<br>
> would make sense to split Weston implemention into 2 distinct ones: a<br>
> barebone implementation with minimal features (architecture + driver<br>
> compatibility) and a full-featured version?<br>
><br>
> I am not saying that the sliding desktop is somehow a bad idea (it is<br>
> a great idea). I do love this feature and will definitely like to see<br>
> it on my desktop. My concern, however, is slightly different:<br>
><br>
> Some people may look at potential opportunities to implement their own<br>
> version of a Wayland-compliant server. These people will likely be<br>
> from different areas and seek some kind of a "Hello world" version of<br>
> a Wayland compliant server. The applications may range from low-power<br>
> portable devices with limited performance to powerful CAD<br>
> workstations stacking dual graphics card firepower. Because<br>
> the requirements and expectations for the graphics interface on<br>
> such systems are vastly different, I am afraid that a W-server that<br>
> aims to be one-size-fits-all may end up being one-size-fits-none. As<br>
> optional features start propagating into Weston it will grow<br>
> into something similar to another X-server, and we are going to be<br>
> back to square 1.<br>
><br>
> I understand that there will be some overhead involved for developers<br>
> to maintain 2 branches. However, most features will probably not fall<br>
> into the barebone version, so the commits for new cool features would<br>
> still be limited to 1 branch only. Bug fixes will indeed be harder to<br>
> commit. Can the 2nd full-featured branch be a library on top of the<br>
> barebone architectural version?<br>
><br>
> Also, is there some sort of a policy or a decision making process as<br>
> to what gets committed into Weston? What do the main developers think<br>
> about 2 branches? I just thought I'd raise these concerns before a<br>
> whole list of optional features gets committed into Weston.<br>
<br>
</div></div>As long as it's restricted to the shells and anything under clients/ I<br>
don't think it matters how much functionality is folded into weston.<br>
Indeed, it's probably valuable, as it helps ensure the core weston &<br>
wayland code can support such use.<br>
<br>
Eventually it might become sufficiently big to do a source split, but<br>
that seems a way off.<br>
<br>
I agree that there needs to be a higher bar than “chuck it in” for<br>
commits touching the core weston compositor, but I don't think I've seen<br>
any commits overstepping reasonable bounds there.<br>
<br>
</blockquote></div><br></div>