Policy check: backward compatibility requirements for CLM?
It occurs to me that some of the CLM patches I've been circulating recently are backward-breaking in some senses. I can make things as backward-compatible as anybody desires; I guess I'd like a steer on how much such compatibility is worth the effort.
Roughly speaking, I can think of 2 or 3 categories of compatibility concerns:
-
[Package exports] Nothing new has been exported from
TOOLKIT
since about 1998, so if there are any third-party CLM programs, nobody's had to cope with "new" name conflicts since then. -
[Wire protocol] Because of the way CLM is implemented, many things must agree between Lisp and
motifd
, and so very many kinds of changes implicitly constitute a new de facto revision of the wire protocol. AFAICT, no such changes have happened in decades, and so there's probably been a de facto "wire compatibility" between different versions of CMUCL andmotifd
for a long time. In particular, it's possible, in principle, that somebody out there might build today's CMUCL for Linux/x86 but be running any oldmotifd
binary going back to 1998, possibly on a different OS or architecture. -
[Source-level backward compatibility for
motifd
] The C sources in src/motif/server plus the headers that get generated during CMUCL build can be used to buildmotifd
for a different OS or architecture than CMUCL runs on. In principle, I suppose, somebody might be able to obtain today's src/motif/server code (plus generated headers) and compilemotifd
using older Motif implementations. If that's meant to be a "supported" mode of using CMUCL's source code & build system, then it implies some constraints on how prospective future changes might go.
These concerns can manifest independently or together: for example, the patch I uploaded here exports a new symbol from TOOLKIT
and affects the wire protocol, but ought to work fine with Motif 1.2. None of the other patches I've circulated affects package exports, but some of them do change the wire protocol (e.g., !81, and the first commit in !79). Finally, Motif 2.0 and later add various features (widgets and such); it'd be possible to add support for these into CLM, but such changes would both change the wire protocol and (unless they were conditionalized appropriately) affect source-level backward compatibility on the C side.
As mentioned, I think I can do things more or less fully backward compatibly, though it'll imply extra stuff for prospective future maintainers to pay attention to:
-
For package exports, the most compatible thing would be to add a new package for anything new (and possibly also everything old), e.g.,
NEW-TOOLKIT
could export all the symbols ofTOOLKI
plus anything extra. (Or, slightly less compatibly but IMO more aesthetically, the existingTOOLKIT
package's exports could go into a package named something likeTOOLKIT-LEGACY
orMOTIF-1.2
or similar, freeing upTOOLKIT
to export new stuff.) -
The wire protocol isn't versioned, so it's necessary to bootstrap some kind of versioning into it. The greet_client exchange in server.c and interface-glue.lisp offers a toehold: the first two bytes from Lisp to
motifd
must be #x01 in some endianness; andmotifd
will quit if the first two bytes are anything else. So, for example, Lisp could send #x02 to try a more dynamic wire protocol validation/negotiation; ifmotifd
exits, the connection closes, and so Lisp could take that as a cue to re-reconnect and use the legacy wire protocol on that connection. In order for this to work, both the Lisp sources and the C sources would all need to keep track of what protocol level different things belong to. (While that sounds tedious, in fact I think it won't be too hard, since a lot is already driven by automatically generated tables.) -
If it's desired to maintain source-level backward compatibility to Motif 1.2, then any newer (Open)Motif features will need to be #ifdef'd or present only in files that are conditionally compiled, I suppose; and the Makefiles in src/motif/server may need to know about that.
Probably I'm overthinking things, but I hate breaking stuff that other people might enjoy. Thanks in advance for any direction here.