--- Robert Strandh strandh@labri.fr wrote:
There are indeed many such problems that need to be addressed. While technically speaking I have the time over the next year to take on this ownership, I do not think I will, because I have at least two more large-ish programming projects to take care of. Though I guess if Dave Murray takes care of Climacs, and someone else of Gsharp, I could work on McCLIM :-)
Perhaps you could consider your work on McCLIM to be the necessary preliminary work for Climacs/Gsharp? ;-)
Also, like I have said many times, McCLIM needs a near-total overhaul in terms of code maintainability and compliance with the standard. So if I were to take ownership, I would not start by fixing immediate problems, but by improving the code in order to make such fixes easier. We are talking at least a few months of work I would think.
Personally I give such a goal three cheers! There are not enough major apps/users to cause a severe upset if this is done right now, so now is an excellent time. Indeed, we might regret it if we don't - maintainable code is a MUST in my book.
Automatic regression testing would be very nice, but it is a huge task in itself. It requires, it seems to me, having understood the spec, which we know is both ambiguous, self contradictory, and incomplete.
Then we should make this goal part of the overhaul - indeed, I see no other viable way to approach it. Perhaps the spec should merge with the McCLIM code and become a literate document - the code in essence being the fully specific expression of the spec? Perhaps the Axiom philosophy is infecting me but it would seem to be an almost ideal arrangement - use Albert or some such to produce a nice, formatted version of the spec from the source code, and maintain spec and code as one document.
A score editor certainly has some limited audience, but it could be a killer app to its particular audience. For that, it needs to work properly, which is why I was planning to work on it a bit more this year.
But CAN it work properly without a revamped and robust McCLIM?
There are two different meanings here to "killer app". The first meaning is an application that is interesting to the general public and that provides functionality that existing applications do not have. Gsharp could become such an application, but it would attract very few, if any, developers.
In open source terms, I still think the ideal "killer app" would be an advanced mathematical document interface. However, that's non-trivial in virtually every way imaginable, and would only attract a few developers. rtoy has broken the ice with a basic interface to Maxima, but a "killer app" level interface would be months and months of work, some of it extremely involved.
The second meaning is an application that is uniquely hackable because it is written in CL and would therefore attract CL developers who would be willing to put up with fewer features than what some similar existing application have, in return for easily being able to add their own features. Closure and Climacs are such applications.
A math interface would definitely not meet this criteria - too specialized.
I really do think that someone would have to sacrifice the better part of a few months to fully read and understand the spec and the code. It would be easier for someone who has already read and understood the spec, of course.
I like your refactoring idea - for McCLIM to take off it should be sufficiently robust to not cause new users any major frustrations beyond learning it in the first place. I personally think the next step should be taken - integrate the spec with the code itself, and iron out any bugs/limitations in the spec that present themselves.
Not that I rate an opinion, of course - actual code trumps mere ideas ;-).
Cheers, CY
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com