Daniel Peter Lepage on Tue, 20 Jun 2006 09:11:24 -0500 (CDT)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [s-d] What news?


> On Mon, 2006-06-19 at 22:58 +0200, Joel Uckelman wrote:
>> It would be easy to write a GraphViz script to represent the House,
>> since
>> it sounds like the House is an undirected graph. (GraphViz produces
>> beautiful output in a variety of formats.)
>>
>
> I was taking a look and there is a GraphViz extention here:
> http://meta.wikimedia.org/wiki/GraphViz
> So we could actually have the map editable from the page.

None of the graphs on that page show up in my web browser (firefox).

> As for parsing the rules and such here is how it would work.
>
> The unformatted rule page would look like this:
>
>
> The rules as of 8/10/2008
>
> ==Section 1==
>
> {{Rule|Wonko has the power|1.1|3|2|Wonko has the power to do anything he
> wants}}
>
> {{Rule|No Whtp|1.2|0|2|Rule 1.1 is invalid}}

How well does this work for longer rules? At one point, rule 301 was well
over 15 pages long, with many subsections. We've also had rules with
embedded ASCII diagrams and other weird things.

Also, is there any easy way to extract single rules? What if I want a page
to show me all rules containing the phrase "Wonko has the power"?

> And what the templating system would do is is format it the way we want
> and fill in the blanks with the data set there. I think css does the
> same sort of thing but I may be wrong.

CSS lets you tell the web browser what formatting info to attach to
various XML tags. It's a similar concept, but the rules would be stored in
XML.

> Also I think you can easily do a database dump into xml but i'd have to
> check.

That would be useful for backing things up, but I doubt we'd want to make
use of it for viewing etc. because it would require keeping two copies of
all data, one in the wiki and one in the XML dump.

The system I really wish we had is this:
We have a program written in Python using the Python Database API, so that
it can be run on top of a number of different database programs (MySQL,
PostGreSQL, ODBC, Oracle, etc.). The program knows some number of types of
documents; types can be added, removed, etc. by anyone with appropriate
permissions. Each type describes the relevant fields, so the type "rule"
has a title and a body, and maybe a list of keywords or a Chutzpah value
or a timestamp, and the type "room" has a name, a description, an
ordinances field, a list of exits, a list of occupants, etc. Every
document also has a revision number, possibly some number of old
revisions, a book, and a section. Various tools for managing these exist,
but they're all clearly written solely as tools for tracking the
information itself, *not* for display.

Separate components then provide the interfaces that expose the functions
of these tools to, for example, a wiki engine. Tools written for MoinMoin
would format the data using MoinMoin's engine and display it accordingly,
and provide forms that fed into the various features of the underlying
document tracker. Other tools written in PHP could provide the same
features through a MediaWiki instance, etc. There would be generic
document viewing tools that could view any document, search by various
fields, etc. We would also be able to add other viewers where relevant,
such as one that reads in all Room data, builds a dotfile for the House,
and renders it into an image map and displays that.

This system would be extremely flexible, would allow all sorts of
extensions to be coded on, and would make the game really easy to
administrate.

Is that feasible? I know that there are nomics with systems kind of like
this - Nomicron certainly has the "general purpose document tracking"
down.

Or should we just stick with something more limited but simpler, like a wiki?

-- 
Wonko


_______________________________________________
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss