Some of the implications, anyway. The benefits of the OS-perspective are > clear. Once it hits its stride, there will be no (technical) barriers to > deploying the sorts of systems that we talk about here > (Croquet-Worlds-Frank-OMeta-whatnot). Others will be doing their own cool > things, and there will be much creativity and innovation. > However, elsewhere in this thread it is noted that the HTML-web is > structured-enough to be indexable, mashupable, and so forth. It makes me > wonder: is there a risk that the searchability, etc. of the web will be > degraded by the appearance of a number of mutually-incompatible > better-than-HTML web technologies? Probably not... in the worst case, > someone who wants to be searchable can also publish in the "legacy" format.
Will the web be degraded by the appearance (or should I say proliferation) of mutually-incompatible, but better than HTML technologies? First off I would ask better in what way? I think the from a user experience POV, I think when people say 'better' they mean richer interactively, which implies better graphical capabilities, access to special hardware (e.g. camera, mic, accelerometer, GPS, GPUs, GPGPU, etc.), faster startup, robustness against network failure and so on. Up until now and may be for some time into the future, the tradeoff of the web as computing platform versus OS-native ones has been about generality versus optimizability as enabled by resource specialization(or some such related thing). Some use cases map well to the general, others not. Only within the last 3 years have we seen mass-market deployment and use of Internet-scale software not entirely based on HTML/JS/CSS client technologies. This has been mostly in the form of native mobile apps. But these are still web apps, many of them still use the Web as connector (e.g. HTTP), but the UI is realized using OS-native frameworks. And so what we often lose is data transparency and portability. For instance, the Our Choice interactive book app on iOS looks and feels great, but its worse than the web in that I cannot even copy text from it. It, like many of the non-ePub digital publications, is just an archive of images and audio-video content pre-baked into a handful of layouts. It's not that non-HTML client technologies degrade the web in and of itself, take PDF for instance. Many PDF documents are linkable and searchable on the web. But this is because software to read PDF is widely deployed, which was enabled by a widespread access to the PDF standard. I think we can mitigate the opacity introduced by non-HTML client technologies if we expand the ways in which we implement links. Imagine encapsulating a reference to the computation (or its type) that would resolve a less-transparent data format. Probably not... in the worst case, someone who wants to be searchable can > also publish in the "legacy" format. The 'legacy' format is the point. I would say that the web isn't 'legacy', but what makes legacy systems visible. If the Internet is a world of many diverse islands of computational and network resources, the Web architecture define languages for these islands to communicate. The issues concerning web client UI rendering technologies are orthogonal to other fundamental issues of the Web architecture. I think what I've been really trying to get at with my initial question is this. If the goal of the web architecture is for connecting resources, the current architecture does well at connecting data, but not computation, not at scale. Perhaps a theme of the developments around HTML5 is evolving the Web architecture to better support connecting applications. But because the Web was designed for exchanging representations of application state (basically large-grained data), so many applications won't fit this model. Imagine trying to run a high-frequency equity trading network atop the FedEx air freight network, or worse the US Postal Service (or chose your local postal service). Add to the fact of a client-server hierarchy and now you have to deal with bottlenecks at those endpoints. Many web-based applications are designed around this bottleneck, and so I see us running into conceptual and structural scaling issues. On Thu, Jun 9, 2011 at 2:56 AM, Josh Gargus <j...@schwa.ca> wrote: > > On May 31, 2011, at 7:30 AM, Alan Kay wrote: > > Hi Cornelius > > 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.) > > I think everyone can see the implications of these two perspectives and > what they enable or block > > > Some of the implications, anyway. The benefits of the OS-perspective are > clear. Once it hits its stride, there will be no (technical) barriers to > deploying the sorts of systems that we talk about here > (Croquet-Worlds-Frank-OMeta-whatnot). Others will be doing their own cool > things, and there will be much creativity and innovation. > > However, elsewhere in this thread it is noted that the HTML-web is > structured-enough to be indexable, mashupable, and so forth. It makes me > wonder: is there a risk that the searchability, etc. of the web will be > degraded by the appearance of a number of mutually-incompatible > better-than-HTML web technologies? Probably not... in the worst case, > someone who wants to be searchable can also publish in the "legacy" format. > > However, can we do better than that? I guess the answer depends on which > aspect of the status quo we're trying to improve on (searchability, mashups, > etc). For search, there must be plenty of technologies that can improve on > HTML by decoupling search-metadata from presentation/interaction (such as > OpenSearch, mentioned elsewhere in this thread). Mashups seem harder... > maybe it needs to happen organically as some of the newly-possible systems > find themselves converging in some areas. > > But I'm not writing because I know the answers, but rather the opposite. > What do you think? > > Cheers, > Josh > > > > > > > Cheers, > > Alan > > ------------------------------ > *From:* Cornelius Toole <cornelius.to...@gmail.com> > *To:* Fundamentals of New Computing <fonc@vpri.org> > *Sent:* Tue, May 31, 2011 7:16:20 AM > *Subject:* Re: [fonc] Alternative Web programming models? > > Thanks Merik, > > I've read/watch the OOPSLA'97 keynote before, but hadn't seen the first > video. > I'm having problems with the first one(the talk at UIUC). Has anyone been > able to watch past the first hour. I get up to the point where Alex speaks > and it freezes. > > I've just recently read Roy Fielding's dissertation on the architecture of > the Web. Two prominent features of web architecture are the (1) > client-server hierarchical style and (2) the layering abstraction style. My > take away from that is how all of abstraction layers of the web software > stack get in the way of the applications that want to use the machine. Style > 1 is counter to the notion of the 'no centers' principle and is very > limiting when you consider different classes of applications that might > involve many entities with ill-defined relationships. Style 2, provides for > separation of concerns and supports integration with legacy systems, but > incurs so much overhead in terms of structural complexity and performance. I > think the stuff about web sockets and what was discussed in the Erlang > interview that Micheal linked to in the 1st reply is relevant here. The web > was designed for large grain interaction between entities, but many > application domain problems don't map to that. Some people just want pipes > or channels to exchange messages for fine-grained interactions, but the > layer cake doesn't allow it. This is where you get the feeling that the > architecture for rich web apps is no-architecture, just piling big stones > atop one another. > > I think it would be very interesting for someone to take the same approach > to networked-based application as Gezira did with graphics (or the STEP > project in general) as far assessing what's needed in a modern > Internet-scale hypermedia architecture. > > > > On Thu, May 26, 2011 at 4:53 PM, Merik Voswinkel <a...@knoware.nl> wrote: > >> Dr Alan Kay addressed the html design a number of times in his lectures >> and keynotes. Here are two: >> >> [1] Alan Kay, How Complex is "Personal Computing"?". Normal" Considered >> Harmful. October 22, 2009, Computer Science department at UIUC. >> http://media.cs.uiuc.edu/seminars/StateFarm-Kay-2009-10-22b.asx >> (also see http://www.smalltalk.org.br/movies/ ) >> >> [2] Alan Kay, "The Computer Revolution Hasn't Happened Yet", October 7, >> 1997, OOPSLA'97 Keynote. >> Transcript >> http://blog.moryton.net/2007/12/computer-revolution-hasnt-happened-yet.html >> >> Video >> http://ftp.squeak.org/Media/AlanKay/Alan%20Kay%20at%20OOPSLA%201997%20-%20The%20computer%20revolution%20hasnt%20happened%20yet.avi >> >> (also see http://www.smalltalk.org.br/movies/ ) >> >> Merik >> >> On May 26, 2011, at 8:38 PM, Cornelius Toole wrote: >> >> All, >> A criticism by Dr. Kay, has really stuck with me. I can't remember the >> specific criticism and where it's from, but I recall it being about the how >> wrong the web programming model is. I imagine he was referring to how >> disjointed, resource inefficient it is and how it only exposes a fraction of >> the power and capability inherent in the average personal computer. >> >> So Alan, anyone else, >> what's wrong with the web programming mode and application architecture? >> What programming model would work for a global-scale hypermedia system? What >> prior research or commercial systems have any of these properties? >> >> The web is about the closest we've seen to a ubiquitous deployment >> platform for software, but the confluence of market forces and technical >> realities endanger that ubiquity because users want full power of their >> devices plus the availability of Internet connectivity. >> >> -Cornelius >> >> -- >> cornelius toole, jr. | ctoo...@tigers.lsu.edu | mobile: 601.212.3045 >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> >> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> > > > -- > cornelius toole, jr. | ctoo...@tigers.lsu.edu | mobile: 601.212.3045 > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > -- cornelius toole, jr. | ctoo...@tigers.lsu.edu | mobile: 601.212.3045
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
