This post is about creating a server side z-code interpreter that represents game progress in the URI. Try it with the game Lost Pig.
I enjoy working on URIs and have the mug to prove it. Along those lines I've combined thoughts on URIs with interactive fiction. I have a limited amount of experience with Inform which generates Z-Code so I'll focus on pieces written in that. Of course we can already have URIs identifying the Z-Code files themselves, but I want URIs to identify my place in a piece of interactive fiction. The proper way to do this would be to give Z-Code its own mimetype and associate with that mimetype the format of a fragment that would contain the save state of user's interactive fiction session. A user would install a browser plugin that would generate URIs containing the appropriate fragment while you play the IF piece and be able to load URIs identifying Z-Code files and load the save state that appears in the fragment.
But all of that would be a lot of work, so I made a server side version that approximates this. On the Web Frotz Interpreter page, enter the URI of a Z-Code file to start a game. Enter your commands into the input text box at the bottom and you get a new URI after every command. For example, here's the beginning of Zork. I'm running a slightly modified version of the Unix version of Frotz. Baf's Guide to the IF Archive has lists of IF games to try out.
There are two issues with this thought, the first being the security issues with running arbitrary z-code and the second is the practical URI length limit of about 2K in IE. From the Z-Code standard and the Frotz source it looks like 'save' and 'restore' are the only commands that could do anything interesting outside of the Z-Code virtual machine. As for the length-limit on URIs I'm not sure that much can be done about that. I'm using a base64 encoded copy of the compressed input stream in the URI now. Switching to the actual save state might be smaller after enough user input.
At the grocery store the other day Sarah and I attempted to find shallot for a recipe, but I can't tell the difference between shallot, sweet onions, yellow onions, etc. etc. We found something that we decided was the closest we'd find in the store and I believe we picked correctly because at checkout the cashier rang it up as shallot.
I think this could be a practical problem that the 20q Pocket Mind Reader should be able to solve: obtain the name of an unidentified object. When we got home I decided to test the 20q Pocket Mind Reader on shallot. Unfortunately, it told me I had an onion, but I think if these were designed for identifying unknown objects based solely on information you can obtain by looking at it, rather than requiring knowledge of seeds, where it grows, etc. it would do better. Or I could just ask someone who works at the grocery store.
I've setup a minimal search page that uses a Yahoo Pipe to sort of search through my content. I say sort of search because I only get full text search over my recent item feeds and otherwise I just search over my tags.
To get real search I'm going to have to keep an archive of all my content on my own website. This is a pain but on the other hand it will let me easily backup my content or display old items on my page. Why didn't I just use a prebuilt solution?
I use my recently added books feed from LibraryThing, a site I've mentioned before where you track, review, recommend, and share your books, and I put the recently added books on my page. I thought it might be nice to include the book covers so I suggested adding book covers to RSS feeds in LibraryThings 'Recommend Site Improvements' group. The next day I had a response from the founder and lead developer Tim Spalding who had started implementing the feature. I noticed a few bugs, reported them on the same thread, and he fixed them soon after. Fantastic! It makes me want to upgrade to a paying account.
Incidentally, if you notice the Ghost in the Shell book appear multiple times in my RSS feed its due to the previously mentioned iterative bug fixes. The same item appeared multiple times slightly differently with each bug fix and your RSS aggregator may have picked them up as distinct items.