Re: [Deskbar] Anticipating future backwards incompatibility

[Sebastian Pölsterl <marduk k-d-w org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nigel Tao schrieb:
> Just a thought I had when playing around with the 2.19 series.  It's
> had a good scrubbing in the refactoring effort, but e.g. extensions
> written for the 2.18 series no longer work.
> 
> It might be possible to write an adapter class to convert a 2.18 style
> Handler to a 2.20 style Module (e.g. wrap or dynamically mix-in or
> some other Python magic) an old-style Handler to add a get_actions()
> method to a 2.18 Match object, for example.  For that to be even
> feasible, we would have to be able to tell the old and new style
> apart.
> 
The only possibility could be that old style handlers return
DummyMatches and the old-style Match gets wrapped by a Action. It's just
a quick thought. However, I think it won't be easy to get old-style
handlers working properly in 2.20.

> Fortunately, we can distinguish between 2.18 (and 2.16 and 2.14) style
> Handlers and 2.20 style Modules because the former live in
> ~/.gnome2/deskbar-applet/handlers and the latter in
> ~/.gnome2/deskbar-applet/modules.  Which is all well and good.  But
> suppose that we do another refactoring in 2.26 that breaks API
> compatibility again.  We might not find a suitable name that isn't
> "Handler" or "Module".
> 
> Thus, it might be better to rename ~/.gnome2/deskbar-applet/modules to
> ~/.gnome2/deskbar-applet/modules-2.20-compatible
> 
> Similarly, we might want to rename history_new.pickle to
> history-2.20-compatible.pickle, or in general, stamp a version on
> anything persistent, in anticipation of future backwards
> incompatibility.
> 
You're absolutely right. If nobody has an objection I'll put it in the
next release on Monday.

> Also, we might require Module writers to implement an
> is_compatible_with(deskbar_version) method or maybe a
> get_module_for_deskbar_version(deskbar_version_string) method.  For
> example, [1] presents a Tracker Handler/Module that attempts to be
> both 2.14 and 2.20 compatible.  I'm not sure if it's best if the core
> deskbar code does this sort of conditional loading, or whether the
> extension writers do this.  It would be nice if, supposing we broke
> the Module API in 2.32, that my old 2.20 Module still worked with
> Deskbar 2.32 since Deskbar 2.32 first asked for a 2.32-compatible
> version and, failing that, adapted a 2.20-compatible version.
> 
That's the smaller problem. If you can write an adapter for old-style
classes this step won't take much.

- --
Greetings,
Sebastian P�erl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG1vDM1ygZeJ3lLIcRAqDWAJoDCYZgSnz3Z0pgIQwl2LcZX6yd+gCgqJM2
2yqxZ07OBNfxOgc57udGmM4=
=tP+v
-----END PGP SIGNATURE-----