LivelyKernel
To make the lively kernel a potentially commercial system, I propose the unix model of users and groups
Let us treat as resources the js objects in the base system, like windows, code editors, clocks, function names, which are essentially all channels of communication courtesy of Shannon, the same way you can think about files in a unix system, btw you can also make everything a file aka resource aka channel of communication courtesy of plan9 wisdom.
Stamp a list of users and a list of groups allowed to edit the resource and/or create for it child resources onto each and every resource. In the existing model, Dan Ingalls is always root in the presentation recorded here: https://www.youtube.com/watch?v=gGw09RZjQf8. Everybody being root, you can be certain of no commercial adoption ever, because software developers in general don't have the wisdom sucked up from doing telecommunications software of Ritchie, Thompson and Pike to marry the morphic model of UI lego like modelling with the unix concepts.
Vision of things that might be: Developer sets up his machine with the developer user, creates widgets, whatever that are editable, including subclassing also by the developer user, except for things the logged_in group should interact with, make those unsubclassable and only editable according to what the user of the web email account or screetch bank account should be able to edit, add users from the anonymous group through a form developed with the same principles, hit submit, new version is serialized to webdav (?!?) server, whatever, what is the internal functioning of livelykernel, everybody receives the new version that sends to the client only the capabilities unrestricted for the anonymous or logged_in groups.
PS: Mabe someone can throw in CRC verification done right and minimally to boot for the base classes that receive and transmit information between the user, local data and the server, what have you with all those software developers trusting the machine to read stuff correctly from main memory or whereever else.
Thanks for sharing your thoughts. Yes, you are right, security and an authorization as well as an authentication model are required to for certain applications. Lively is structured in a few layers, one of them is Morphic (the graphical and interactive user interface) and indeed, no security implementation is part of the Morphic model.
Integrating a security model that combines server-side authentication with a client-side capability-based access restriction is certainly possible. An interesting tension exists, however: A goal of the Lively environment is to provide a learning environment and a programming system that should allow "casual" application creation. Providing an open and unrestricted system is our first goal -- in terms of the applications that can be created as well as the conceptual "power" needed for a self-evolving. Arguably, the Lively implementation in its current state is not simple enough to even reach those goals fully. Adding another layer of complexity to the Morphic implementation we have will not help with that, I fear.
There are various applications that use Lively only in part (library code, persistence, etc) and implement a front-end using other means than Morphic. This approach also allows to implement a customized security scheme and is what we recommend at the moment.
Please note that for Lively's wiki features an authentication and authorization system exist that controls read / write access on the HTTP-level: https://github.com/LivelyKernel/life_star-auth
As per http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html, no one will ever push for LivelyKernel type stuff into public schools, only business type CEOs and politicians have a real influence on that level. Also there is a hugely better implementation in the form of Etoys that has not received code updates in a long time after the stabilization of the main features, and its popularity has stabilized to the level where it was driven by university level academic funding.
I would also like to point out that during Dan Ingall's presentation there was that awkward moment when a developer wanted to address exactly this issue seeing all the good stuff that is there, and ending up calling the project, mockingly, a prototype of a prototyping system. So there will be no adoption on the enthusiasts side as well when they try and build real systems. It will just not occur to them to retrofit the needed things into the kernel and they'll build something else from, looking specifically at the Java world, commercial off the shelf IDE's and frameworks.
For a headscratcher I would like to point you to what rob pike had to say about other people integrating features in BSD and SunOS and everywhere, that ended up in the Unix and then the Linux API and way of doing things, which was from the point of view of someone with an experience in commercially scaling telecommunication systems, an abomination:
Instead of mounting network sockets in the filesystem and using all the kernels facilities for files with a unified API, and use the concept of users and groups to manage network devices, they did special case stuff for all of it and dumped it into the kernel API. So now application programmers and kernel developers have to push along source code structures that only move APIs up the hill.
Considering that stuff like that happens in a military academic system mimicking a telecommunications commercial system, I would say that, by analogy, not reintegrating in the correct way access control, for each individual aspect of the system, in the guts of the LivelyKernel, right in this codebase, and then trumpeting all the new commercially viable features, will doom it at the exact moment when the academic funding and/or interest dries out, for everything including teaching.
Oops, I accidentally closed the issue. I reopened it to make it visible again.
Was there a discussion/analysis somewhere on the net about comparing the "everything is an object" approach to the "everything is a file" approach?
Seems like both have merits - and frankly as noted above some of the plan9 demos have a "lively" feel to them. Sure enough plan9 doesn't come with Morphic, but some of the "use the file commands to control anything, including processes and windows" and some of the "distributed" UIs/processes demos are quite remarkable.
It seems from some of the talks I've seen that Alan Kay is traditionally quite critical of the "command keywords calisthenics" that unix puts users through. But I was wondering if the "better versions" of Unix such as plan9 have actually more in common with lively environments (in terms of using compositions of a few system-wide mechanisms to satisfy plenty many use cases) than usually thought.
Is there any assessment/comparisons over the two approaches "everything is an object" and "everything is a file" anywhere? If not, is there a mailing list or a forum you'd advise to have such conversation?
interestingly enough, later in the day I went through this paper: http://plan9.bell-labs.com/sys/doc/names.html , and I found this fitting paragraph:
"At this level of abstraction, files in Plan 9 are similar to objects, except that files are already provided with naming, access, and protection methods that must be created afresh for objects. Object-oriented readers may approach the rest of this paper as a study in how to make objects look like files."
@davidedc A bit more general but Dick Gabriel's Worse is Better is a classic
- http://www.dreamsongs.com/WIB.html
As you mentioned, related are the ideas behind Plan 9 which basically brings the file and object world together (at least on the UI level)
- http://www.openu.ac.il/home/wiseman/sds/plan9.pdf
- http://plosworkshop.org/2013/preprint/kell.pdf
The c2 wiki is always fun to delve into and has both shortsighted and considerate comments
- http://c2.com/cgi/wiki?IfSmalltalkIsSoGoodWhyDoesNobodyUseIt