> On 31 May 2011 16:30, Alan Kay <alan.n...@yahoo.com> wrote: >> There are lots of egregiously wrong things in the web design. Perhaps one of >> the simplest is that the browser folks have lacked the perspective to see >> that the browser is not like an application, but like an OS. i.e. what it >> really needs to do is to take in and run foreign code (including low level >> code) safely and coordinate outputs to the screen (Google is just starting >> to realize this with NaCl after much prodding and beating.)
The web is not *only* an OS. It also provides the backing data for a very large unstructured database. Google of course realize this, as their company rests on a search engine. The semantic web folks have tried in vain to get people to add more structure to the database. What the "web OS" must do is allow the efficient export of additional *unstructured and ad hoc* data. HTML+CSS web applications today are moderately good at this -- the images stored in flickr (say) are still in standard crawlable formats, and they show up in search results. Google's Native Client (as well as prior sandbox technologies, such as Java, etc) is *not* good at this (yet?). The graphics rendered in NativeClient are completely invisible to search engines -- and thus resources created in these apps are impossible to index. You can build a web app *alongside* Native Client in order to export data created in the sandboxed app -- but now you're just doubling the effort. Like it or not, the messy stew of HTML+CSS is the closest we have to a universal GUI canvas, loaded with equally-messy semantics -- but enough that I can take the source code for a (say) flickr or youtube page and extract the comment text and photos/video. No rival "web application" or "web as OS" framework (which is not itself built on HTML+CSS) can do that. --scott ps. the closest rival to HTML is RSS/Atom -- a more limited format, but it had it's own search engines and tools (see http://www.opensearch.org). A "web OS" which could still export its underlying data structures/files as a indexable/sharable/browsable RSS feed would be more competitive than a pure sandbox. Another possible avenue is exporting from your "web OS" something close to a "filesystem" -- ie, a list of downloadable "documents", nothing more -- and letting the search engine "peek inside" the standard format of the documents to construct an index, as Google can currently do with PDF, XLS, and other common file formats. But this gives up the idea of the 'hyperlink' -- now I know there's a binary blob somewhere with information relevant to my search, but it comes without any code to edit/view/collaborate. (For a little more detail on the "export as RSS" aspect of this, you might check out "The Journal, Reloaded" at http://cscott.net/Publications/) -- ( http://cscott.net ) _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
