Anastasia and Collate Blog

WordPress database error: [Table './sdeblog/wp_users' is marked as crashed and should be repaired]
SELECT * FROM wp_users WHERE ID = '2' LIMIT 1

November 19, 2006

What’s wrong with Anastasia now — 2006

Filed under: Anastasia faults — @ 6:28 pm

WordPress database error: [Table './sdeblog/wp_users' is marked as crashed and should be repaired]
SELECT * FROM wp_users WHERE ID = '2' LIMIT 1

Environments change: software, like other lifeforms, changes with the environment or it passes away. Now, in 2006, the computing environment in which Anastasia lives is very different from that in which I first imagined her, in those far-off days of 1993. Anastasia 2.0, as she now is, is still in important respects a child of those times. Then, there was a tendency for software to be ‘greedy’: to try to do everything possible. So Anastasia 0.1 was a search engine, a SGML handler, and a browser — as indeed was DynaText. Now, in 2006, the tendency is the reverse: for software tools to try to do one thing only, really well, and to cooperate with other tools which do other things. This is particularly true of web applications, where a federation of tools may work together to place the text on the screen: the server to receive the request, a database module in the server to fetch content from a database, a XSLT module to transform the content, and finally a browser to display the page.

There had been other changes. XML did not exist when I first imagined Anastasia — though I think I can claim a rather unique insight into the first days of XML. Around 1994, I think it was, I stayed some days in the spare room of Elli Mylonas and David Durand’s house in Providence, Rhode Island. On a table in the room, among computer discs and old coffee mugs, there was a scrap of paper, with handwritten notes on it. These were notes by David Durand of a conversation he had had with Steve DeRose — then chief scientist of DynaText, and (with David, then and now) a pillar of text encoding ideas. The notes were headed ‘what’s wrong with SGML’ and indeed appeared to be a wishlist for a system to replace DynaText. It contained, from memory, the following items:
HAVE NO CHOICES
EXPLICIT ENDTAGS ALWAYS
NO DTD
FIX MIXED CONTENT
FIX ATTRIBUTES
Indeed, XML does just this. By 2000, XML was set to sweep the world, and within a few years, it had done so. And with XML came a plethora of tools, new standards, documentation: for connectivity to databases, for document validation, transformation, querying. In 2001, I was able (thanks to the genius of James Clarke’s SP tool) to convert Anastasia to a tool for handling XML as well as SGML. But Anastasia had its own system for doing all the things these new tools could do. It stood outside this rush of new development and you could not use the new tools with Anastasia

Now, in 2006, this makes Anastasia look distinctly out of place: like a visitor from another era. Several events conspired to persuade us that Anastasia, in its current form, cannot survive. These were:
1. The popularity of other XML tools led users to expect that Anastasia could handle XSLT, XPATH, XQUERY and related technologies. When they learnt it could not, they went elsewhere.
2. We found that for some purposes, we needed to connect Anastasia to a database. But we found that managing database connections, at the low level of a C-language module within a server environment, extremely difficult, and extremely sensitive to changes in the other packages we had to use. At the same time, we saw all around us convenient and robust database tools that we could not use, because of the architecture in which we were trapped.
3. In 2001, we had decided to bind Anastasia to the Apache server. This led to all kinds of problems. Firstly, we had written Anastasia to work with Apache 1.x. But Apache was moving to 2.x. It would be a truly major effort to rewrite Anastasia for Apache 2.x. There were other problems with the Apache dependency too. Apache runs notoriously poorly on certain Windows configurations (so much so that Apache advise against using Apache as a production server in Windows); we found mysterious problems in some Linux systems (particularly, dual-processor systems) and slow memory leaks in all systems which we struggled for long periods to resolve.
4. Anastasia relies upon TCL scripts to do its magic. Some people love TCL (not unreasonably, in my view); some hate it; most know nothing about it and when told of it, say ‘what?’. It is taught in few computer science courses, and the mere mention that to use Anastasia requires TCL is enough to send most people away.
5. More and more, people want to use systems build around combinations of tools: databases, php, cgi-bin, perl. In effect, Anastasia in 2006 says: use me, in preference to anything else. In the CD-ROM publishing context for which Anastasia was originally devised, there is virtue in this simplicity. Just install Anastasia, and you can do what you want. But in complex server environments, where people use different tools for different purposes, this was a profound defect.

So, through 2006, we (mostly Andrew West and I, but with frequent discussions with others) thought hard about Anastasia 3. A ‘tipping point’ came in August 2006. Andrew and I spent a week in Munster, as we had done many times before, with the intention of spending the whole week working on the digital Nestle-Aland Greek New Testament. But on the first day, Andrew struck a memory problem deep within Anastasia: he and I then spent the whole week trying to resolve these problems. We realized we simply could not afford to do this, over and over. We realized too that our difficulties in finding and fixing this problem stemmed from the complex dependencies between Anastasia, the Apache environment, and the php module with which Anastasia must interact. After this experience we knew we could not continue as we were. We must have an Anastasia 3 — or find something else which could do what we wanted.

Powered by WordPress