On Sun, Jul 24, 2011 at 10:24 AM, Alan Kay <[email protected]> wrote:
> The main idea here is that a windowing 2.5 D UI can compose views from many > sources into a "page". The sources can be opaque because they can even do > their own rendering if needed. Since the sources can run in protected > address-spaces their actions can be confined, and "we" the mini-OS running > all this do not have to know anything about them. > This idea of 'opaque' applications in a sandbox may result in a flexible UI, but not an especially composable or accessible one. Consider the following desiderata: * Accessibility - for screen-readers, search engines, language translators. * Zoomability - we should be able to constrain client-side resource consumption (CPU, bandwidth, memory) such that it is commensurate with user attention (as measured in terms of screen real-estate for visuals, or volume for audibles). * Service mashups and customization - grease-monkey scripts and extensions that modify an app require it have a clear structure. * Occasionally connected computing - links fail, power isn't always up, we might persist an app we aren't zoomed on at the moment. * Mobility - an app should be able to follow users from one computer to another. * Bookmarking, Sharing, CSCW - users should be able to share access to specific elements of their applications. * Optimization - the later we perform optimizations, the more we can achieve, especially if the language is designed for it. Access to the underlying code can allow us to achieve higher levels of specialization. This is how apps work on personal computers, and there is no reason why > things shouldn't work this way when the address-spaces come from other parts > of the net. > Except, being opaque is also part of how apps consistently *fail their users * on personal computers. I.e. we should not be striving for apps as they exist on personal computers. Something better is needed. I agree that NaCl for Chromium is a promising technology. Though, I wonder if hardware virtualization might be more widely accepted. But the promise I see for NaCl isn't just rendering flexible apps to screen; rather, I see potential for upgrading the basic web abstractions, breaking away from HTTP+HTML+DOM+JS+CSS for something more robust and consistent (I'm especially interested in a better DOM and communications protocol for live documents). I.e. it would be easy to create 'portal' sites that effectively grant access to a new Internet. This offers a 'gradual transition' strategy that is not accessible today. > this [NaCl] approach will need to be adopted by most of the already > existing multiple browsers before it can really be used in a practical way > in the world of personal computing > I agree that this is a problem for apps that can be easily achieved in JS. (And the domain of such applications will grow, given WebGL and WebCL and improved quality for SVG.) But for the applications where JS and WebGL are insufficient, mandating Chrome as a platform/VM for an application should rarely be 'worse' than providing your own executable and installer. > > The sad and odd thing is that so many people in the computer field were so > lacking in "systems consciousness" that they couldn't see this > What's with the past tense? Regards, Dave
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
