Wkg at Writing & Design 
|
Home?
- For DOS-users who want to try a simple demo of making local calls from a Web page: check this out.
- (note: the CGI-script for the following may not be activated yet) For a cross-platform demo comparing a local image call with a GET from the server: try this one.
- And thanks to my Webmaster for pointing out Voyager's CDLink, which just goes to show that CD-Web is an idea whose time has come.
Got a Write-Once? Meet CD-Web: A new product idea that's not a virtual studio but has some of the advantages of one. CD-Web can be practical for developers working at a distance with raw multimedia files. It can help the client get involved and pitch ideas on how to combine files for effect. CD-Web is also a more-affordable way to produce education (it will also allow curricula to be subjected to quantitative analysis), entertainment and game titles because you don't have to program the front-end.
Everybody loves the WWW front-end, but it's held back from its full multimedia capabilities by limited bandwidth and the compatibility issue of different users' helper applications for MIME extensions. MPEG, sound files, JPEG images, all are perfectly suited to the dense storage specs of CD-ROM. Only you can't play a CD on a Web page. Oh yeah?
If groups of Web users are provided with identical CD-ROMs full of raw image, video and sound files, Web pages can be created with URL calls to these local file resources. Getting matching CDs to a group with special interests is bound to be easier than the "nightmare" (p. 9 of net.genesis & Hall's Build a Web Site ('95).) of ensuring compatibility of helper apps. CD-Web delivers local files faster than T1 (see Chart) and lets you use the readily-accessible medium of Web-publishing to compare creations between different members of the CD-using group.
Internet Transmission Rates CD-drive Rates 9.6 Kbps =
14.4 Kbps =
56 Kbps =
T1 = 1.54 Mbps =
T3 = 45 Mbps =1.2 KB/sec
1.8 KB/sec
7 KB/sec
192 KB/sec
5.625 MB/sec
1X = 150 KB/sec
2X = 300 KB/secThe right way to do it would be to use a custom protocol which gives the user a pull-down menu item, activating a text box into which they enter local path information. When the browser sees the custom protocol it then sends the URL and local path info out the API interface. The localhost path is then prepended to the original URL to create a resolved URL which is fed back into the browser as an HTTP protocol (big thanks to Walter Ian Kaye for his help with this!). The problem with doing CD-Web the right way is that the software is still under development (note: major browser provider considering adding this capability).
The way to do this immediately with everyday HTML is by misinforming the <BASE> tag with false local information (using the FILE protocol). <BASE> is an empty tag contained by <HEAD>...</HEAD> with syntax: <BASE HREF="URL">, and is normally used to indicate the original location of an HTML document that has been transported. Hyperlinks in the original document made by relative URL's to files in the same subdirectory (or its children) remain valid even when the document has been dragged onto some far off server, because the <BASE> tag's path info is prepended to any relative URL's in the document.
So <BASE HREF="file:///d|/filename.html"> will direct a DOS machine (with D: for its CD-drive) to search for any relative URL's on the CD, even though the Web page itself is actually on the World Wide Web. Macintosh platforms need to use the name label of the disc itself. So you have a choice: either save the Web page as code and then add the <BASE> info, or duplicate nearly-identical documents on the Web which are accessed by hyperlinks at a start-up page, for example: "You may access either the D: Windows version or the MPEG ROCK VIDEOS Macintosh version of this document."
Philip Merrill |