Gopher 2.0?
I designed some column browser code for browsing files (or any XML) with JavaScript. It needs some extending (e.g., to handle write operations like rename/delete/drag-and-drop move/etc.), but it basically works.
Now for browsing files over the web (or even representing local files), the question becomes what standard to use.
While the column browser can currently be used to browse through the tags of an HTML page, it'd be more useful I think if the now ubiquitous HTML (at least in XHTML form) could represent file hierarchies in a predictably browseable fashion, as the now long dying Gopher protocol does/did. Yes, we often like pictures and rich textual context to get to our pages of interest (as well as on our pages of interest), but often (like in Yahoo Directory), we just want to drill down quickly to our pages.
(Gopher inherently encourages such quick "drilling down", but I mention column browsers specifically because it enables a much faster navigation (most Gopher browsers to my knowledge use the file system equivalent of "icon view" where you have to click rather than being also able to use the arrow and letter keys on the keyboard and view more than one level of the hierarchy at a time, though it'd be cool to have "list/tree" view and "column view", to borrow other OS' terminologies).)
I've considered (and am still considering) XML formats like METS, but I wondered whether the <link/> and <meta/> facilities in HTML could be "good enough" given their familiarity to developers.
So, the title attribute on <link/> gets used in place of the Gopher protocol's "User_Name" field, while Gopher's Selector, Host, and Port are discernible from the href attribute. The type attribute, meanwhile, gives the equivalent of Gopher's Type field.
That's it! (The only question really is whether we can overload the Gopher protocol for use in HTML as our own--I think it's better than adding my own custom URL for a profile, but maybe others disagree...)
We might be able to use meta tags if we wanted a more fail-safe way to translate into actual gopher files, and referencing each link's id:
...though I don't think this would really be necessary both because A) the <link/> can probably be readily translated into the equivalent fields (Type being a little more difficult), and B) Gopher as is is not being used much anymore.
(One should also be able to use <a rel="" href=""/> instead of <link/> since the profile on <head> would be good enough to indicate this was a different type of application (and would avoid duplication), but I used <link/> since they were all there in one place in the head for easy and fast retrieval, and one wouldn't need to necessarily show the links to HTML users (or choose how to do so).)
Then the question becomes to me (besides the profile choice mentioned above), what protocols (gopher2:...) and header types (application/x-gopher2+xml?) could be used to induce our Gopher-specific behavior in clients (such as Firefox which can have extensions made to handle such cases)... Of course, it'd be cool while in regular HTML mode to be able to opt to Gopher mode, but maybe some would like to recommend/force the Gopher type (especially if the HTML body didn't contain much or if the document was really intended to offer the fuller navigational facilities of our Gopher 2 and the author didn't want the user to be bothered to have to manually choose to start Gopher mode, even if the browser informed him of its Gopher 2.0 support).
I'm also interested in the following which also might depend on such a representation of files (and raise similar questions about protocols):
Both of the above would benefit from being able to represent a hierarchy of files...I wonder whether that could be solved by such as the following:
Now for browsing files over the web (or even representing local files), the question becomes what standard to use.
While the column browser can currently be used to browse through the tags of an HTML page, it'd be more useful I think if the now ubiquitous HTML (at least in XHTML form) could represent file hierarchies in a predictably browseable fashion, as the now long dying Gopher protocol does/did. Yes, we often like pictures and rich textual context to get to our pages of interest (as well as on our pages of interest), but often (like in Yahoo Directory), we just want to drill down quickly to our pages.
(Gopher inherently encourages such quick "drilling down", but I mention column browsers specifically because it enables a much faster navigation (most Gopher browsers to my knowledge use the file system equivalent of "icon view" where you have to click rather than being also able to use the arrow and letter keys on the keyboard and view more than one level of the hierarchy at a time, though it'd be cool to have "list/tree" view and "column view", to borrow other OS' terminologies).)
I've considered (and am still considering) XML formats like METS, but I wondered whether the <link/> and <meta/> facilities in HTML could be "good enough" given their familiarity to developers.
<html>
<head profile="http://tools.ietf.org/html/rfc1436"><!-- Gopher -->
<!-- we could also get fancier with the following and
use xml:lang, hreflang, charset, media, id -->
<link title="My first file in the directory" type="text/html" rel="next"
href="http://example.com/some_link.html" />
<link title="My second file in the directory" type="text/plain" rel="next"
href="http://example.com/some_link2.txt" />
<link title="Another gopher2 'directory' file like this one"
type="application/x-gopher2+xml" rel="next"
href="http://example.com/gopher2dir.html" />
</head>
<body>
<p>Could have <a href=""/> links here for manual viewing, or just indicate
this is a "Gopher 2.0" document</p>
</body>
</html>
So, the title attribute on <link/> gets used in place of the Gopher protocol's "User_Name" field, while Gopher's Selector, Host, and Port are discernible from the href attribute. The type attribute, meanwhile, gives the equivalent of Gopher's Type field.
That's it! (The only question really is whether we can overload the Gopher protocol for use in HTML as our own--I think it's better than adding my own custom URL for a profile, but maybe others disagree...)
We might be able to use meta tags if we wanted a more fail-safe way to translate into actual gopher files, and referencing each link's id:
<html>
<head profile="http://tools.ietf.org/html/rfc1436"><!-- Gopher -->
<meta name="Type" scheme="gopher" content="_1:h"/><!-- The first parameter
is the link id below, while the part after the separator, here 'h', is
the gopher type -->
<!-- Use scheme attribute to distinguish from any other profiles in
use on the head? -->
<meta name="Type" scheme="gopher" content="_2:0"/>
<meta name="User_Name" scheme="gopher"
content="_1:My first file in the directory"/>
<meta name="Selector" scheme="gopher"
content="_1:/some_link.html"/>
<meta name="Host" scheme="gopher"
content="_1:example.com"/>
<meta name="Port" scheme="gopher"
content="_1:80"/>
<link id="_1" title="My first file in the directory" type="text/html" rel="next"
href="http://example.com/some_link.html" />
<link id="_2" title="My second file in the directory" type="text/plain" rel="next"
href="http://example.com/some_link2.txt" />
<link title="Another gopher2 'directory' file like this one"
type="application/x-gopher2+xml" rel="next"
href="http://example.com/gopher2dir.html" />
</head>
<body>
<p>Could have <a href=""/> links here for manual viewing, or just indicate
this is a "Gopher 2.0" document</p>
</body>
</html>
...though I don't think this would really be necessary both because A) the <link/> can probably be readily translated into the equivalent fields (Type being a little more difficult), and B) Gopher as is is not being used much anymore.
(One should also be able to use <a rel="" href=""/> instead of <link/> since the profile on <head> would be good enough to indicate this was a different type of application (and would avoid duplication), but I used <link/> since they were all there in one place in the head for easy and fast retrieval, and one wouldn't need to necessarily show the links to HTML users (or choose how to do so).)
Then the question becomes to me (besides the profile choice mentioned above), what protocols (gopher2:...) and header types (application/x-gopher2+xml?) could be used to induce our Gopher-specific behavior in clients (such as Firefox which can have extensions made to handle such cases)... Of course, it'd be cool while in regular HTML mode to be able to opt to Gopher mode, but maybe some would like to recommend/force the Gopher type (especially if the HTML body didn't contain much or if the document was really intended to offer the fuller navigational facilities of our Gopher 2 and the author didn't want the user to be bothered to have to manually choose to start Gopher mode, even if the browser informed him of its Gopher 2.0 support).
I'm also interested in the following which also might depend on such a representation of files (and raise similar questions about protocols):
- Links (e.g., using a custom protocol) which can indicate a package of files to download and store locally--e.g., for offline browsing--if they are not yet downloaded, and reference page numbers, special views of the data, etc. if it is already downloaded; this would work like HTML 5's offline applications, but would allow links which could refer to someone else's data--e.g., if someone downloaded a specific book (in XML or database form) from a particular site (or with a particular URN perhaps), one could click a link at another site to trigger a view of that same book (a specific page or paragraph range, a selection of font and colors, etc.). (Maybe this is like combining the cross-site Ajax with offline applications--let links be made to reference the same data in different ways?)
- Navigable site maps, ala "Standard sitemap", but which can have links lead to browse other sites as well...
Both of the above would benefit from being able to represent a hierarchy of files...I wonder whether that could be solved by such as the following:
<html>
<head profile="http://example.com/our_sitemap_protocol">
<meta name="next" scheme="sitemap" content="level1:level2" />
<link title="Home page" id="level1"
href="http://mysite.com/home.html" />
<link title="Contact page" id="level2"
href="http://mysite.com/contact.html" />
</head>
</body>
</html>
posted by Brett at
1:38 AM
|
0 comments
