Re: spoon-discuss: So, what should I be doing?

["David E. Smith" <dave@xxxxxxxxxxxxxxx>]

On Sun, 17 Feb 2002, Donald Whytock wrote:

> Were I to be greedy...

Indeed. ;)

> I'd want more intrapage links, so that if r123 references r234, the
> reference to r234 would be a link to r234, so that I can flip back and
> forth between the two rules.

I'd want something like that too, actually. :-)

I'm a bit short for good ideas on how to implement it, though.

There are two really obvious ideas:

* Go through the whole ruleset and edit everything by hand. I don't really
want to do that, because the ruleset is up to about 40 pages. (Yeah, I
printed it out.)

* Find a way to do it at runtime. Really tricky... It's hard for software
to distinguish between "Rule 100" and "starts with 100 points" in any
meaningful way.

If you're just looking for meaningful groupings of rules, just suggest
more keywords. Since I now have the authority to add Keywords to the
database more-or-less at my discretion, and since it's really really easy
to do, that may have to suffice as a stopgap.

> Maybe an alphabetized rule name index at the beginning of the rule list.

That would be relatively easy to do... I'll try to bang one out.

> Definitely a place for Limbo above or below the Grid, because, thanks
> to football, things being in (1,1) may become an issue.

Definitely in the queue.

I may end up re-doing the whole Grid system again at some point. The
system I've got now is fairly good for most things that occur
infrequently, but moving those Gremlins around for GremBall is frankly a
pain in the ass.

> BTW, a thought about the database...Do you store the actual text of
> objects in the database, or is that stored in files that are
> referenced by the database?  Which do you think would be less of a
> resource drain: hauling lots of text out of the database, or opening
> several text files in succession?

The rules are stored in one big database table.

Though I haven't formally benchmarked anything like this, I imagine the
"lots of text files" would be more draining. PHP and MySQL offer lots of
stuff to make database use reasonably efficient - persistent connections,
a fair amount of internal caching, etc. And there's the less-tangible
benefit of the fact that everything is already IN the database.

Rules, proposals, and CFJs are all stored in one big table that has the
object number and revision number, object type, title, text, other stuff
(nweek of origin, "owner" for proposals, and so on). Since every revision
of every object is stored as a separate row, there's a total of 557 items
already in there.

If you want to look at the current rules, you can either:
* Make a couple quick queries and iterate through the result set
or
* Open up several hundred text files and start parsing like a madman.
(There's 217 items in the database with type "rule", but that includes all
previous revisions of rules. I'm too tired to count up all the current
revisions right now.)

The database also has tables for players, the grid, dimensions, and
keywords. Most of those are fairly self-explanatory.

...dave