When this site was vandalized, I lost the newer instructions on how the query language works. The result is that the instructions are missing all the newer features I added after about August 2004, and the LARP Schema is behind the times. I need to bring both back up to snuff.
Along with generally fixing up the query documentation that had been lost, I need to add the newest mechanism, which allows a page query to have clauses of the form "World==Garden". Also, page queries can now include variable references in the query, and the restriction can include PAGENAME, so you can have page queries like "% %IS_A% %==PAGENAME" -- this is wonderful for allowing us to have really generic display templates.
One consequence of having schemas is that I find that I now really want to be able to share those schemas between Wikis. I have a fairly complex schema for LARP development, and it's a pain in the tuchus to have to copy all of it each time I add a new LARP. (Worse, maintenance is almost impossible.) So it would be lovely to have some mechanism that allows me to share pages between multiple Wikis -- to have a separate Wiki that represents a common subset of all of them.
Dealing with permissions in this environment wouldn't be easy -- we want to be able to edit the shared schema from any of the constituent Wikis. Maybe it has its own config, with its own special permissions, so that only certain users can edit those?
Idea inspired by jikharra: instead of having the parent link at the page header that goes to the base class, have a chain of links showing the ancestry (probably in small print below the title?), each of which goes to a listing of that class. That would probably be more useful, most of the time.
It would be convenient to have a variable form (like "% %#VARNAME% %"), that means "the number of VARNAME" thingies. This would allow me to easily tally, eg, how many archetypes I have.
It would be useful to have a page property on page X that simply means "redirect to page Y", to make name changes easier.
When editing, there is a Save button. It would be useful to have a Save and Continue button as well, which would simply submit the current changes and return to the editing state.
Currently, all values for a given property wind up getting read in, in their entirety. This could potentially be a problem, since one can easily see a single property table winding up a full megabyte.
The tentative solution is to only include the beginning of each property value in the file. The first 100 (50?) bytes of the values would go into the property file, plus a tag that indicates that the rest has to be fetched from the actual file. This means that short properties would still be read in a single pass, but long ones don't bulk up the property file. It trades off a few more small file accesses against some very large ones.
I'll decide to do this, and figure out the tuning values, once it begins to become an issue.
The system needs a lot of hammering and error-checking. One consequence of properties is that there are now many more ways to create an illegal page. We should be detecting that illegality at edit time, and return appropriate errors, telling the user to try again.
I should also hammer on inheritance cycles, and make sure you can't send the system into an infinite loop. The code is intentionally designed (sometimes a bit obliquely) to ignore cyclic inheritance -- things are generally structured so that cycles will automatically terminate. But this really hasn't been tested yet.
I've gotten very used to being able to double-click on a page to edit it, from other Wikis. Add this to the generic page HTML.
This one's ambitious, but could be the killer app for ProWiki. Since the data is stored in a structured way anyway, why not publish that way? Now that serious Semantic-Web tools are starting to come out (such as Simile Piggy Bank, at "http://simile.mit.edu/piggy-bank/index.html"), ProWiki would become enormously more useful if the page's data was available as an RDF table, as well as in HTML. Indeed, I suspect that it's steam-engine time for this particular idea, so I should do it soon.
A corollary to this is that I probably need to introduce some sort of ability to formalize a schema. This needs to be done with some care, since I am fond of ProWiki's loose structure and ability to create schema-free pages. But the RDF capabilities are likely to work more smoothly if there is some way to predeclare a schema and have pages adhere to it unless they intentionally do otherwise.
This begins to move in the direction of a wholesale rewrite, but it's time to start thinking about that. ProWiki would probably work better if it was built on top of a true DB, rather than flat files. This database would be pretty simple: probably single table with five columns -- Namespace, Page, Property, Version and Value. There would be several indexes for various purposes: Namespace/Page? for ordinary rendering, N/Property? for queries, and so on. Think about how versioning plays into this -- in particular, what does it mean to have the version of an entire page, and how does that relate to the versions of its component Properties?
Of course, the implication is that I really should restart with a more solid and current Wiki technology that is already DB-based, something that runs on top of MySQL? preferably. Which such Wiki I use isn't clear. I lean towards a Ruby-based solution, but I'd also like to merge into a major existing tech. Need to examine the options here...
Having gotten crap about the use of the ProWiki name (it isn't a technology, but it is a site), let's choose a new name that doesn't conflict for version 2.0. After some thinking about looking around, I believe the new name will be Querki, for "Queryable Wiki".
Okay, time to get seriously started on the redesign. See Querki Design Notes for discussion.