Metakit (was Wiki issues)

To give this a bit of additional perspective (and because a lot of 
people - not Neil though, I should add - have been slamming Metakit the 
last week or so without understanding it)...

Like any good tool, Metakit is at its best when used properly in the 
situations its designed for.  Using it like MySQL in a CGI-based web 
environment is certainly not what its designed for.  Despite that, as 
Neil notes, its worked well enough for years, but ran into some issues 
when severely pushed the last few weeks.  Given that wikit was a pretty 
quick hack many years ago that has not had much attention given to it, 
it's probably says something about how effective Metakit can be even 
when explicitly used in an environment that was not a good fit.

FWIW, Metakit does support concurrency between threads (when given a 
badly documented option), but that's still not the way it was designed 
to be used.  In the wiki case, switching off of CGI scripts but using 
either a fileevent/single-thread or a single-process/multi-thread 
approach would have been more than enough to address this.  The CGI 
model (multiple processes all writing to a Metakit database) is not what 
it was designed for.  To say nothing of the fact that running an active 
site on CGI these days, especially on as old a box as we have been, 
should be considered sheer madness. :-)

Use it properly, for a problem domain where it makes sense and in the 
correct environment, and Metakit is ridiculously hard to beat.  With 
ProjectForum (Tcl/Metakit based wiki) I've got a server running hundreds 
of wikis, many of them larger and more active than the Tcler's wiki, and 
each far more feature-rich, and the server barely breaks a sweat.  And 
that's not using some of the best techniques that would push Metakit 
performance even faster.  Going the traditional database route, I'd be 
very hard pressed to get anywhere close to that (I bet SQLite could do 
it, because it and Metakit share a lot of characteristics in terms of 
the types of problems they are good for, and the environments they are 
designed to run in).

Arguing what is "best" is foolish, but talking about the tradeoffs in a 
particular situation is wise, especially if you actually understand what 
those tradeoffs are.  Metakit is a niche database, no question, and if 
used in the niche it was built for, you're likely going to do better 
than a more broad-based solution.  

This community, of all groups, should certainly appreciate the immense 
value of niche solutions. ;-)

Mark

(who is not advocating Metakit or any other solution for whatever the 
future version of the Tcler's wiki becomes; just about anything would 
work fine if used properly)

Hi Mark,




I understand. But surely Jean-Claude is aware of this concurrency
issue. I cannot imagine he hasn't tried some kind of mutual exclusion
between his CGI processes. Moreover, I remember here on clt many years
ago, he "invented" a very elegant pure-Tcl , system-wide, readers-
writer exclusion scheme:

    - single writer lock: [file rmdir $dir]; unlock: [file mkdir $dir]
    - multiple readers lock: [open $dir/$id w]; unlock: [file delete
$dir/$id]

So, what's going on ? What mutex principle is at work in wikit ? Isn't
it the above ? Is it flawed ?

-Alex