Updating the story archive

[Nevar]

I was wondering if there was anyone out there that would like to work on updating the story archive, so there is one collection of files with all the stories together. It could be released periodically (not sure about hosting) . Anyone interested, leave a message here or send me a private message.

[rextorres]

I can provide reliable hosting for the story archive since I have a website that is paid for on an annual basis. You just need to provide the files.

[nypup2train]

Precautionary disclaimer (AKA "This ain't my first login at the cyber cafe", M-x mommie-dearest-mode): None of the comments I'm about to make are in any way intended to ignore or detract from the contributions and accomplishments of all those who've helped make the site, and its story archive, available to us all. Without their efforts, I wouldn't have anything to comment ON. I am grateful to all those who enable my guilty pleasures. (as well as those of every other site member.) Inevitably, anyone determined to find my comments offensive or rude will succeed in doing so. Such people -- more likely NOT anyone directly involved, I predict, but rather "passionate" outside observers -- are unable to comprehend constructive criticism, or indeed any input other than fawning, do-no-wrong encouragement. Toothless praise is anathema to progress and advancement. I cannot help those people. They have my blessing to go ahead and be horrified at my lack of manners.

Part of the difficulty, I fear, may be that the Archive thus far (the 070326 .ZIP distribution) doesn't lend itself to being update-ABLE, particularly. As a one-shot publication it's just fine, the format serves its purpose well and it's internally consistent and workable. But issues of possible future releases, incremental updates, and the like (which I've churned a bit in a back-of-my-mind way), as well as possible enhancements to the current offerings, are where it doesn't fare as well.

The major obstacle to any update of the current archive is in the numbering and ordering. Each "article" (to designate a specific term, used to refer to a single displayed (non-index) page from the archive -- either an entire one-shot story, or a single chapter from a multi-part one) is numbered, sequentially, from 1 to 4363. They happen to be in alphabetical order by title, with an N-chapter multipart occupying a contiguous block of N IDs.

Some of the functionality occurs naturally as a result of this. The title index page ultimately represents a listing of articles in numerical order. The "Next" and "Prev" buttons simply link, from any given page N.html, to N+1.html and N-1.html. This has the effect of linking the chapters of a multi-part story together, but almost by accident.

Updating a "solid" structure like that poses a challenge. If a new chapter is added to a story, there's no "space" open for it in the existing structure. Either article IDs have to be shifted over (and as a result the entire archive ends up renumbered), or new additions are numbered starting from the end of the list, no longer in order.

If new chapters are placed at the end of the list, no longer in order, then "Next" and "Prev" become fairly useless, and the task of reading through the chapters of a multi-part story becomes an arduous and complicated one.

If the archive has to be completely renumbered, then any bookmarks, links, or other references to archive content are immediately invalidated, which may be frustrating for some. In addition, there's no possibility of providing "incremental" content, via a small .ZIP of just the NEW articles (and indexes) that can be extracted in the same location as the previous archive in order to update it.

...There are a few other, smaller issues. For instance, the single monolithic index page isn't likely to be practical should the archive grow bigger. (It may not seem like a major concern, most of the time, but you would not believe how long it takes to load and render that page on the Pentium-166 sublaptop I use as a bookreader. Even using a text-mode browser! At some point it's going to grow too large to display at all, with only 64MB of RAM.) Breaking it up into 27 sections (alpha, plus one for 0-9+symbols) would be a help, tho "Find-in-page" would no longer be sufficient to search the story list then.

I think a 2-level indexing -- every story identified as an individual unit, where each one is possibly made up of multiple chapters viewable either randomly or linearly -- would provide a lot more flexibility in updating and expanding existing content. It's pretty much the same structure used in the Nifty archive... not to suggest blindly duplicating their structure. (I don't think the category-based hierarchy would make any sense, for instance.) But it's a useful real-world example that seems to be effective in practical application.

*shrug* Just some thoughts, nothing more.

[nypup2train]

Originally Posted by nypup2train

*shrug* Just some thoughts, nothing more.

...And they're not even correct ones, at that. *sigh*

Ignore all this noise...

Originally Posted by nypup2train

Each "article" (to designate a specific term, used to refer to a single displayed (non-index) page from the archive -- either an entire one-shot story, or a single chapter from a multi-part one) is numbered, sequentially, from 1 to 4363. They happen to be in alphabetical order by title, with an N-chapter multipart occupying a contiguous block of N IDs.

Some of the functionality occurs naturally as a result of this. The title index page ultimately represents a listing of articles in numerical order. The "Next" and "Prev" buttons simply link, from any given page N.html, to N+1.html and N-1.html. This has the effect of linking the chapters of a multi-part story together, but almost by accident.

It's wrong, quite simply. The Next/Prev functionality jumps around quite a bit, article numbers aren't remotely in order. (Except for small pockets, purely coincidental. I based my faulty assumptions on a few of those, it seems.)

Of course, this fact makes "updating" the archive an even trickier procedure, as it means that existing pages MUST be changed (their Next/Prev links updated) as part of the process of adding new articles to the archive. So incremental updates are simply something it wasn't designed to handle. C'est la vie.

-Pup

[Nevar]

We may just have to eliminate the prev/next for a short term, till we can rework everything, and design the updatability in it.