[mcclim-devel] McCLIM 2.0 in 2008

[Troels Henriksen]

So, McCLIM is already pretty old, and while I can't claim to have
worked on it for more than a year and a half, I feel like I have a
pretty good grasp of what it does, and how well it does it. Perhaps we
should start wondering about releasing a "stable" McCLIM, that is, one
that is feature complete (with relation to the CLIM spec) and more
tested than out usual releases. I'm not saying we should slap a stable
version number on the 0.9.6 release, just that I think it would be a
good, and achievable, goal to release a stable version this year. What
would need to be done to make this happen? Here's a preliminary list,
if you feel it is incomplete, please add to it:

     * First, implement all the reasonable parts of the CLIM 2 spec,
       with the exception of things that are unimplementable,
       underspecified or just really hard to do properly (fully
       generic designs, alpha blending and all, falls in this last
       category, I think). Things that are underspecified should
       probably be implemented by looking at later CLIM specs, as well
       as classic CLIM behaviour. We are already mostly there. Does
       anyone know exactly what is missing?

     * Create a better test suite, at least something that can
       actually be called a test suite, though it may not fully test
       the entire system. This is probably a must if a "stable"
       release is to have any meaning at all, and fortunately, many of
       the tricky aspects of CLIM do not actually need a graphical
       interface, and the Null backend may suffice for the majority of
       the rest. I would prefer using an actual regression testing
       library (such as FiveAM) compared to files filled with asserts.

     * Select a number of extensions (not necessarily all of them) and
       make sure they're as well tested as the core CLIM
       functionality. These extensions should also be documented.

     * Have at least one backend without major flaws. I think the CLX
       backend is good enough, apart from some suboptimal
       performance. Gtkairo may not reach that level this year.

     * Insert docstrings for all exported functionality. If I recall
       correctly, Robert Strandh spoke with one of the original CLIM
       spec authors and was told not to worry about copyright issues,
       so we could just copy from there.

The following is what is NOT necessary for a McCLIM 2.0 release:

     * Support for LispWorks and Allegro CLIM extensions.

     * Fully working and tested extensions. We only need to select
       those that are feasible to bring up to a sufficiently high
       level of stability and performance (does this leave out
       mcclim-freetype?). Of course, we should document which ones.

     * More than one fully working backend.

     * Documentation covering CLIM itself. The spec will have to do
       for now.

Finally: when you saw this email, none of you thought "I wonder what
insightful observations this thoughtful engineer has about a stable
release", you thought "why is this crazy hacker talking about a 2.0
version, we're still pre-1.0!". My idea is to make the McCLIM version
number follow the CLIM spec version number. While this is not terribly
useful for a 2.0 release in isolation, it makes it easier to design
similar 2.1 and 2.2 releases for the LispWorks and Allegro extensions,
as well as the hypothetical future CLIM 2.3 spec that will fix all the
ambiguous and underspecified details and bring CLIM into the 90's.

What are your thoughts?

-- 
\  Troels
/\ Henriksen - who's quite sleep-deprived