Unstable protocol name breakage

Tue Oct 20 19:56:20 PDT 2015

On Tue, Oct 20, 2015 at 06:42:24AM +0200, Mariusz Ceier wrote:
> On 20 October 2015 at 05:59, Jonas Ådahl <jadahl at gmail.com> wrote:
> 
> > On Tue, Oct 20, 2015 at 05:26:45AM +0200, Mariusz Ceier wrote:
> > > Hi,
> > >
> > > On 20 October 2015 at 04:22, Jonas Ådahl <jadahl at gmail.com> wrote:
> > >
> > > > Hi again,
> > > >
> > > > I was about to start migrating generic protocols away from weston into
> > > > wayland-protocols. The idea was to start with input-method.xml,
> > text.xml,
> > > > linux-dmabuf.xml, presentation_timing.xml, scaler.xml and
> > xdg-shell.xml.
> > > > The
> > > > question, however, is what to do with the names, because some names
> > already
> > > > have the form "wl_[name]", and renaming such an interface to
> > "zwl_[name]1"
> > > > during the unstable period, and then back to "wl_[name]" will cause
> > > > potential
> > > > breakage because some implementations in the wild might expect the
> > > > "wl_[name]"
> > > > to be the original (ancient) version.
> > > >
> > > > As mentioned before, I have already moved the fullscreen shell
> > protocol,
> > > > and
> > > > with the naming schema changes in place, it ended up with the protocol
> > name
> > > > "fullscreen-shell-unstable-v1", the interfaces zwl_fullscreen_shell1,
> > and
> > > > zwl_fullscreen_shell_mode_feedback1.
> > > >
> > > > linux-dmabuf.xml is also easy. Since it is already 'z' prefix, to
> > comply
> > > > with
> > > > the intended naming schema, I'd just need to rename the interfaces to
> > > > zlinux_dmabuf1 and zlinux_buffer_params1, and the protocol to
> > > > linux-dmabuf-unstable-v1.
> > > >
> > > > presentation_timing.xml: I suppose this one can be renamed without any
> > > > significant implications, since it currently is completely prefix
> > free. I
> > > > imagine it'd be zwl_presentation1 and zwl_presentation_feedback1 in a
> > > > presentation-timing-unstable-v1(.xml) protocol.
> > > >
> > > > The problem is the rest of the protocols, since they all already have
> > the
> > > > intended stable names. This means we cannot apply a naming schema that
> > > > intends
> > > > to finally remove the prefix and postfix when declaring stable, since
> > that
> > > > would collide with the initial name. How to deal with these names
> > needs to
> > > > be
> > > > decided, and probably so protocol by protocol.
> > > >
> > > > scalar.xml: As far as I know, Pekka has plans to change scalar.xml, and
> > > > plan to
> > > > do so with a name change. So as far as I understand, we need to rename
> > this
> > > > one.
> > > >
> > > > input-method.xml: This one I think might actually be fine to just
> > apply the
> > > > naming schema, as the protocol itself has Wayland core principle
> > violations
> > > > that need to be solved, i.e. any implementor of this is already broken
> > (by
> > > > principle).
> > > >
> > > >
> > > Since it's broken by principle, can't input-method.xml be marked as
> > > deprecated (e.g. by implementing/using top-level deprecated attribute ) ?
> > > Then leave it in weston as weston-specific protocol, that generates
> > > deprecation warnings during compilation and maybe when used by clients
> > > connecting to weston; and in wayland-protocols add new protocol that's
> > not
> > > broken by principle (but may be based on input-method).
> >
> > Not sure what you mean with top-level deprecated attribute (attributes
> > on some C code? or disable the text-backend by default whith a warning
> > if its enabled?).
> 
> 
> I meant adding deprecated attribute to top-level <protocol> element in .xml
> file, that would instruct
> wayland scanner to generate deprecated attributes for every interface
> that's defined in this xml file.

It will only make building weston produce lots of warnings. It won't
affect the third party clients since they still have their own copies.

> 
> If we disable it by default we'd just break third
> > party clients (and can just as well move and rename), and I don't think
> > we should have compiler warning by default.
> >
> >
> I didn't mean disabling it - just generate deprecation warning at runtime
> (in weston) and compile time when client uses deprecated protocol.
> 
> I don't know if it should be deprecated though; the broken-ness is that
> > it breaks the single-origin of object factories because it creates a
> > wl_keyboard, but that can be fixed.
> >
> >
> Will the fix most likely break existing clients ?

Yes.

> 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.
> In all other situations - input-method.xml should be fixed, 'z' prefix
> added and such modified protocol moved to wayland-protocols.

This is the question I asked, and I was hoping the author / maintainer
of those protocols could make that call.

Jonas

> 
> If wl_input_method is no longer expected to be used by anyone, nor be
> > fixed, then I think we should deprecate it, or even easier, just remove
> > it.
> >
> > >
> > > Deprecation can also be used for other problematic protocols, but I'm not
> > > sure if that's good idea if such protocol is not broken.
> >
> > If a protocol is replaced by another, I think it makes sense to
> > deprecate it. Or if it is problematic for any other reason for that
> > matter. What compositor implements deprecated protocols is not a
> > question for wayland-protocols however.
> >
> > >
> > > text.xml: This one I'm not so sure about. Has it ever been implemented
> > > > outside
> > > > of weston except only as a proof of concept? Would it be fine to use
> > the
> > > > same
> > > > name?
> > > >
> > > > xdg-shell.xml: Should we bite the bullet and rename this one, or just
> > > > continue
> > > > letting its stability state be non-discoverable? It's clearly already
> > > > used, and
> > > > renaming it will be painful, so not sure about this one.
> > > >
> > > >
> > > Maybe we should at first stabilise protocols that are used, not broken
> > and
> > > renaming them will be painful ?
> >
> > We should not declare protocols stable that are not ready just because
> > they happen to be used in the wild. For the protocols that can be
> > declared stable as is with the reason they are actually ready, now is a
> > good time to do so indeed, but the reason should be right.
> >
> >
> > Jonas
> >
> > >
> > >
> > > > Then comes the IVI protocols. I have no opinions about these, and I
> > don't
> > > > know
> > > > what any plan with them might be. Should they be moved, or are they
> > purely
> > > > a
> > > > weston thing?
> > > >
> > > > For the rest of the protocols (desktop-shell.xml, screenshooter.xml,
> > > > text-cursor-position.xml, weston-test.xml, workspaces.xml) I plan to
> > leave
> > > > them
> > > > be, as they either are purely weston internal, simple toy protocols or
> > > > have no
> > > > consesus that they are to be ever be official protocols.
> > > >
> > > > So what should we do about these naming issues? It should have been
> > clear
> > > > that
> > > > all of these are experimental protocols, but due to the fact that some
> > may
> > > > have
> > > > started to use these outside of weston anyway even though they being
> > > > experimental, is it Ok for us to start causing them to break? If not,
> > what
> > > > may
> > > > some alternative names be?
> > > >
> > > >
> > > > Jonas
> > > >
> > >
> > >
> > > Mariusz Ceier
> >