Let me stump again for my kind of solution (XML or no XML; flat file would work just as well). It would be easy enough to write a script that goes through the generated files and builds up a list of titles, or that spits out the node corresponding to a given title (this is beginning to sound like fun, actually!).

I don't see that there's a significant benefit to storing each node in its own file anyway. Or perhaps you can explain why you want to do it this way?

Philosophy can be made out of anything. Or less -- Jerry A. Fodor

The method behind my madness, so to speak, was that a given user could then fairly easily translate the nodes to a group of html files, one to a topic -- if, for instance, one had written extensively about a topic and wanted to make the information available to those who don't use E2 or Google.The initial version (which, admittedly, isn't posted yet) allows one to use a regexp to select which writeups a given user wants to save from the database, which could apply equally well to a single-file mode.

I was planning some sort of single-file functionality eventually, particularly so that one could pull out a group of nodes, revise them, and then auto-node them back into the database. I'm uncertain whether or not XML is the way to go, given I'm hardly an XML expert (or a Perl one, for that matter). Perhaps a single-XML-file option and a single-"text" file option.

FWIW, an E2 user whose code I <strikeout>stole</strikeout> borrowed from (don't worry, it's GPL) to create it suggested the following regexp to me: $nodefilename =~ y,/:\\?'*&quot;&lt;&gt;;&amp;!\0,,d;
, and I use a separate operation to translate spaces to underscores unless an option is selected that prevents this (for instance, if one is running Windows).