Unstable protocol name breakage

[Mariusz Ceier]

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.

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151020/25b7857d/attachment.html>