<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 October 2015 at 05:59, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Oct 20, 2015 at 05:26:45AM +0200, Mariusz Ceier wrote:<br>
> Hi,<br>
><br>
> On 20 October 2015 at 04:22, Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br>
><br>
> > Hi again,<br>
> ><br>
> > I was about to start migrating generic protocols away from weston into<br>
> > wayland-protocols. The idea was to start with input-method.xml, text.xml,<br>
> > linux-dmabuf.xml, presentation_timing.xml, scaler.xml and xdg-shell.xml.<br>
> > The<br>
> > question, however, is what to do with the names, because some names already<br>
> > have the form "wl_[name]", and renaming such an interface to "zwl_[name]1"<br>
> > during the unstable period, and then back to "wl_[name]" will cause<br>
> > potential<br>
> > breakage because some implementations in the wild might expect the<br>
> > "wl_[name]"<br>
> > to be the original (ancient) version.<br>
> ><br>
> > As mentioned before, I have already moved the fullscreen shell protocol,<br>
> > and<br>
> > with the naming schema changes in place, it ended up with the protocol name<br>
> > "fullscreen-shell-unstable-v1", the interfaces zwl_fullscreen_shell1, and<br>
> > zwl_fullscreen_shell_mode_feedback1.<br>
> ><br>
> > linux-dmabuf.xml is also easy. Since it is already 'z' prefix, to comply<br>
> > with<br>
> > the intended naming schema, I'd just need to rename the interfaces to<br>
> > zlinux_dmabuf1 and zlinux_buffer_params1, and the protocol to<br>
> > linux-dmabuf-unstable-v1.<br>
> ><br>
> > presentation_timing.xml: I suppose this one can be renamed without any<br>
> > significant implications, since it currently is completely prefix free. I<br>
> > imagine it'd be zwl_presentation1 and zwl_presentation_feedback1 in a<br>
> > presentation-timing-unstable-v1(.xml) protocol.<br>
> ><br>
> > The problem is the rest of the protocols, since they all already have the<br>
> > intended stable names. This means we cannot apply a naming schema that<br>
> > intends<br>
> > to finally remove the prefix and postfix when declaring stable, since that<br>
> > would collide with the initial name. How to deal with these names needs to<br>
> > be<br>
> > decided, and probably so protocol by protocol.<br>
> ><br>
> > scalar.xml: As far as I know, Pekka has plans to change scalar.xml, and<br>
> > plan to<br>
> > do so with a name change. So as far as I understand, we need to rename this<br>
> > one.<br>
> ><br>
> > input-method.xml: This one I think might actually be fine to just apply the<br>
> > naming schema, as the protocol itself has Wayland core principle violations<br>
> > that need to be solved, i.e. any implementor of this is already broken (by<br>
> > principle).<br>
> ><br>
> ><br>
> Since it's broken by principle, can't input-method.xml be marked as<br>
> deprecated (e.g. by implementing/using top-level deprecated attribute ) ?<br>
> Then leave it in weston as weston-specific protocol, that generates<br>
> deprecation warnings during compilation and maybe when used by clients<br>
> connecting to weston; and in wayland-protocols add new protocol that's not<br>
> broken by principle (but may be based on input-method).<br>
<br>
</div></div>Not sure what you mean with top-level deprecated attribute (attributes<br>
on some C code? or disable the text-backend by default whith a warning<br>
if its enabled?). </blockquote><div><br></div><div>I meant adding deprecated attribute to top-level <protocol> element in .xml file, that would instruct </div><div>wayland scanner to generate deprecated attributes for every interface that's defined in this xml file.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we disable it by default we'd just break third<br>
party clients (and can just as well move and rename), and I don't think<br>
we should have compiler warning by default.<br>
<br></blockquote><div> </div><div>I didn't mean disabling it - just generate deprecation warning at runtime (in weston) and compile time when client uses deprecated protocol.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't know if it should be deprecated though; the broken-ness is that<br>
it breaks the single-origin of object factories because it creates a<br>
wl_keyboard, but that can be fixed.<br>
<br></blockquote><div> </div><div>Will the fix most likely break existing clients ? </div><div>If yes - do we care about that (since protocol is not yet stable, we don't have to) ? If yes - IMO current input-method should be deprecated, left in weston (as weston-specific) and new protocol created in wayland-protocols.</div><div>In all other situations - input-method.xml should be fixed, 'z' prefix added and such modified protocol moved to wayland-protocols.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If wl_input_method is no longer expected to be used by anyone, nor be<br>
fixed, then I think we should deprecate it, or even easier, just remove<br>
it.<br>
<span class=""><br>
><br>
> Deprecation can also be used for other problematic protocols, but I'm not<br>
> sure if that's good idea if such protocol is not broken.<br>
<br>
</span>If a protocol is replaced by another, I think it makes sense to<br>
deprecate it. Or if it is problematic for any other reason for that<br>
matter. What compositor implements deprecated protocols is not a<br>
question for wayland-protocols however.<br>
<span class=""><br>
><br>
> text.xml: This one I'm not so sure about. Has it ever been implemented<br>
> > outside<br>
> > of weston except only as a proof of concept? Would it be fine to use the<br>
> > same<br>
> > name?<br>
> ><br>
> > xdg-shell.xml: Should we bite the bullet and rename this one, or just<br>
> > continue<br>
> > letting its stability state be non-discoverable? It's clearly already<br>
> > used, and<br>
> > renaming it will be painful, so not sure about this one.<br>
> ><br>
> ><br>
> Maybe we should at first stabilise protocols that are used, not broken and<br>
> renaming them will be painful ?<br>
<br>
</span>We should not declare protocols stable that are not ready just because<br>
they happen to be used in the wild. For the protocols that can be<br>
declared stable as is with the reason they are actually ready, now is a<br>
good time to do so indeed, but the reason should be right.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Jonas<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> > Then comes the IVI protocols. I have no opinions about these, and I don't<br>
> > know<br>
> > what any plan with them might be. Should they be moved, or are they purely<br>
> > a<br>
> > weston thing?<br>
> ><br>
> > For the rest of the protocols (desktop-shell.xml, screenshooter.xml,<br>
> > text-cursor-position.xml, weston-test.xml, workspaces.xml) I plan to leave<br>
> > them<br>
> > be, as they either are purely weston internal, simple toy protocols or<br>
> > have no<br>
> > consesus that they are to be ever be official protocols.<br>
> ><br>
> > So what should we do about these naming issues? It should have been clear<br>
> > that<br>
> > all of these are experimental protocols, but due to the fact that some may<br>
> > have<br>
> > started to use these outside of weston anyway even though they being<br>
> > experimental, is it Ok for us to start causing them to break? If not, what<br>
> > may<br>
> > some alternative names be?<br>
> ><br>
> ><br>
> > Jonas<br>
> ><br>
><br>
><br>
> Mariusz Ceier<br>
</div></div></blockquote></div><br></div></div>