[mcclim-devel] McCLIM 2.0 in 2008

Troels Henriksen writes:

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 think this is a laudable goal, and even if it doesn't happen, having this goal might make progress faster in 2008.

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:

The more general problem I see is that whenever I feel like working on some feature of McCLIM, I feel stymied because of the lack of maintainability of McCLIM.

For that reason, I think an effort like this should start with some preventive maintenance activities such as:

* Remove commented-out code, or uncomment it.

* Add signed-and-dated comments to difficult passages whenever reasonable.

* Make sure McCLIM compiles with as few warnings as possible

* Add references to the spec for code that implements some required functionality.

* [and probably some more things that I can't think of right now]

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

It is hard to tell what is missing because some parts of the spec are optional, such as color blending for instance.

Also, color blending would be easy to implement if we had a backend such as the one I started a while back that would use a single CLX window as a frame buffer.

But it might not be highest priority to implement all of the spec. I would say it is more urgent to make the parts that are currently implemented work according to the spec. I am thinking of things like output-record inheriting from standard-rectangle and then assuming all output records do so.

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

Sounds good.

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

Again, this sounds good, but that's partly because whether this is reasonable or not depends on what (if any) such extensions are selected.

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

I think we should have at least one backend that uses a single mirrored sheet (the graft, I suppose), so that we can test unusual sheet transformations and such. The X-window-as-frame-buffer backend I suggested above would do that, but perhaps Gtkairo will as well.

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

I am starting to think that docstrings are evil (because they are mostly noise to the person reading the code). I would like to discuss the possibility of using (SETF DOCUMENTATION) instead.

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

 * More than one fully working backend.

See above. The CLX backend might not be good enough for testing everything we would like.

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

What do you mean by this?

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.

Sounds like a good suggestion to me.