Month: June 2008

Idea: TV Style Subscription Service For Games

On By clearwaterstreamIn games, service, subscription, TV1 Comment

Games can be developed same ways TV shows are produced. You play an episode of a game and wait until next week to play the next episode. This will make it easier for game developers, for example, to push out the game. All they have to do is produce the first episode (which is much shorter than normal game) and release it into the public. In the meantime the developers can work on the next short installment, due next week. The consumer would then subscribe to a cable style service where he/she can opt to play several different games that are released in TV show fashion. Similar to having 40 channels in a basic package. Either that or the consumer pays per game.

Give users the chance to shape the series.
Since the game is being developed in short installments, ask the audience using things like polls (and/or by collecting statistics) how the next episode should play out. This will make the game a bit more interactive and feel more custom tailored should your vote influence the outcome.

Idea: OS Level Spell Check

On By clearwaterstreamIn Spell check, spell-checkingLeave a comment

The newly introduced Firefox 3 has built-in spell check. That got me thinking, why not introduce spell checking in the OS level rather than trying to implement it for each program? It will allow all the spell check development to be focused in one place, providing better product. There are already system-wide spell check programs out there, now we need OS development folks to implement the same idea.

Idea: HTTP Get Multiple Files

On By clearwaterstreamIn HTTP GETLeave a comment

This functionality can easily be jammed in into existing browser and server code.

Summary:
Basically, a browser will parse html file and compile a list of files (like JavaScript, images, etc…) that it needs to get from server(s). For example, if the browser sees something like this in html <img alt="google logo" src="http://www.google.ca/intl/en_ca/images/logo.gif” /> it will not make a request to get the image but rather will add it to the list of files to get.
Once the list is ready, the browser sends an HTTP GET request to each server (links within HTML can point to many locations) with the list of files it needs.
The server gets the files and compresses them to an archive (zip for example) with correct relative directory structure and serves it to the client.
The client, knowing the file received is in fact an archive, extracts it and gets multiple files in one shot!

How to implement in Browser:
In the ProcessHTML() function, that’s before DisplayHTML() function, get all the links that need a GET request and add them to an array. There will be an array for each server. For example, my HTML might have links to 10 images located somewhere on google.ca and another 10 somewhere on advertize.com.
For each array execute a GET with the filename being “?this is a multi file request. filenames are “. So the filename will not be a legal URI.
The server will return an archive with the files and relative directory structure.
Extract the archive to a temp location and replace all the links within HTML that point to external locations to the ones that point to your local hard drive. For example: <img alt="google logo" src="http://www.google.ca/intl/en_ca/images/logo.gif” /> will be replaced with <img alt="google logo" src="file:///C:/BrowserTempFolder/www.google.ca/intl/en_ca/images/logo.gif” />.
Then, invoke the DisplayHTML() function.

How to implement in Server:
If the incoming GET request has a filename that start with “”?this is a multi file request. filenames are” DON’T try to do an I/O operation as the filename is not legal and the I/O operation will fail. Instead, jump to a function that will parse out the filenames and put them in an archive that has relative directory structure.
Give the archive to the client, that’s it!

Notes:
The browser should have logic that will determine if doing the above makes sense. Say I am parsing a web page that has 40 images. Would the above functionality have benefit? Yes (assuming the images are tiny). How about one or two images? Probably not. This also assumes that the client / server already have support for HTTP Compression, which modern servers and clients do.