Hi Scott, I tend to agree with you. The uniform interface of the web (reduced set of HTTP verbs, links...) is what make all these applications possible. We know what to do when we have the URL to the flickr image. But we could do so much more.
A simple multi-media document definition language with a protocol to manipulate these documents (similar to AtomPub but at a lower level, maybe like MIME) would allow us to create much more powerful applications. In particular, it would automatically give us addressing of any part of a document. The different applications would not have to define their own addressing scheme like it is the case today with DOM, CSS, URL fragments... Regarding the "graphics rendered in NativeClient", I don't think it would necessarily require to have a web service alongside of the application to make the data available to other services. Your application (UI part) can be built on top of the structured document model and protocol mentioned above. A set of "view rules" would render the output of a process (structured data) to the user and transform user input into a set of commands in the underlying uniform protocol. Of course, these view rules would also be documents that can be managed using this same protocol. I imagine this architecture as a gigantic mesh of independent processes exchanging structured data using a uniform protocol. As a user, I can change the state of the mesh by observing and changing data at some points of the mesh. -- benoit On Fri, Jun 3, 2011 at 10:58 AM, C. Scott Ananian <csc...@laptop.org> wrote: >> 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 > _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
