Unstable protocol name breakage

[Jonas Ådahl]

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?). 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 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.

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