This is my current major project. The goal of this project is to replace the web browser with something much better. Rather than have a browser which downloads HTML and formats it, the browser will interact with distributed objects across the Internet and let them render themselves on the user's screen. This would mean that code is loaded from remote machines and executed locally.
From the user's point of view, this project provides a "SiteBrowser", which is similar to a web browser. The SiteBrowser shows "Sites", which are similar to web sites. The SiteBrowser has a "back" button, a "history" button, etc, and the main area of the SiteBrowser UI is the currently visited Site with which the user interacts.
A Site is similar to what a "Project" is now in Squeak. Sites are distributed objects. When a Site is visited by a SiteBrowser, it is given a Canvas to draw itself on and has some way of receiving UI events.
In this way, applications can be written which can run across the Internet. There is no need to install applications; they are accessable simply by visiting the Site that they are implemented on. Example applications would be word processors, simple games, database-like applications and so forth.
UIDesign ReactiveUIDesign BetterIDE LocationService
Do you want to help? If so, send me an email (mikevdg at gulik.co.nz).
Currently I'm working on SecureSqueak. See the "Versions" section for unfinished items and pick one that interests you.
My plan is to get SecureSqueak to a certain level of stability where people can use it as a base for their own projects.
A UGP client or server would be made out of the following components:
Status: In progress.
This is the "base" of this project. SecureSqueak is a fork of Squeak which allows untrusted code to run locally in a secure, sandboxed and resource-limited environment.
SecureSqueak is a large project in itself. I plan to make it reusable for other people's projects.
Status: Prototype only.
The "SiteBrowser" is the user interface that the user will see. It manages browsing between sites and keeping track of the user's "history" (so that the "back" button works).
Current code is on http://www.squeaksource.com/SecureSqueak
Status: Actively coding this as of Nov 2008.
This is the UI drawing and event management. A Canvas class exists already in Squeak, but I plan to expand it significantly.
Subcanvas is part of SecureSqueak.
Status: Prototype only.
Dominions are a resource management system. Resources, such as CPU time and disk space, can be allocated to a particular dominion. A dominion could potentially span multiple computers, and using DPON, those resources are available for the dominion owner to run his distributed applications on.
In other words, a "dominion" can be thought of as a virtual supercomputer. Computer owners can give (or sell) their computer's resources to a particular dominion.
Dominions are part of SecureSqueak.
Status: Works, but very unstable.
DPON is a distributed object replication framework, which will handle replicating the Sites between computers. Currently work is on hold (although I poke it now and then) until SecureSqueak is finished.
DPON is complex and pre-dates this wiki. See here for a very old write-up about it.
Status: Not yet designed.
Users in this project will have public/private keys which can be used to authenticate users. In this way, usernames and passwords are not needed for every single site the user visits.
The "user management system" is open; there is no central repository for users. Rather, a user creates an "account" by creating a public key pair and "user" object locally. Dominions may be associated with users.
Ideas for a UGP / DPON specification to allow other people to implement clients.
The UGP client has the minimum necessary functionality needed to load the rest of the system. It is built on SecureSqueak. This way, system updates can be made from a central server. The remotely loaded code from the central server needs to be trusted with the local devices and is the code that will manage security for other untrusted services.
The UGP client boots up. It manages a Canvas (whole screen(s)), Event handlers, Networking, Dominions, Namespaces, DPON, User key management. The UGP client is somehow given user information from which it then reads the location(s) of a boot server from and loads the rest of the code for that user's desktop. The "user's information" is ideally a single file which contains a username, public keys and the location of the user's account.
The UGP client then asks the user's account for a user interface coordinator. This coordinator manages the screen(s) (Canvas(s)), keyboard/mouse events and local devices (filesystems, sound, ...). Services such as cut/copy/paste, widget sets, navigation, user notifications etc are handled by higher levels of code.
...for speed, perhaps the image that has booted over the network should be saved and restored?
A UGP server stores the user accounts.
Thought: A user's account could be a dominion?
A remote server should appear as an interactive object. The user would manage dominions on these servers, and replicated objects would migrate to these dominions.
We want to get the UGP installed on people's computers as easily as possible.
Invent SqueakLoad.
Most preferred: stand-alone application.
Power-users need a .zip file or .exe install file.
Make a file format and associate it with the UGP, e.g. a_link.ugp -> starts up squeak+image with this file.
- Under windows, there's an application finder - how does this work?
- Under Linux, this is a MIME type.
- MacOS?
With a file format for links to sites, those links could be put in web pages, emails, file browsers. Link files could be saved from within UGP.
Ideally the user's credentials will be associated or associatable with an opened link file.
Firefox / IE plug-in? No - the SiteBrowser has its own navigation, authentication, caching and so forth; making it a plug-in would confuse the user. Instead, have some file association or link of some sort from an HTML page which would open up the SiteBrowser as a separate application on that link.
Perhaps I could make a mini-installer (VM + small image) which downloads image, starts image, restarts image on crash, manages logs and image backups, receives link files and starts up new image or sends it to an existing image, ...? Maybe it could be written in C with versions for each OS? Make sure it gives the user a good experience:
This mini-installer could have the file association. When initially started, it searches for Squeak. If it cannot find it locally, it will download Squeak.
Installations will have:
Computers would have some IT support responsible for looking after that computer. This might be a single user, an organisation or it might be me. This support specifies:
Security policy for a computer would be specified by the dominion that that computer will be part of. Security policy of the user would be specified by that user's identity.
Specifying the dominion that a computer would be part of could be done by:
Specifying the security of the user would be done by the administrator of that user (which could be the user himself).
The security policy for a user specifies:
Links:
http://support.microsoft.com/kb/929149 - describes default handling of application associations in Windows XP+.
The 1.0 release is a major milestone that will take a long time to reach. Beyond the horizon, these are some features that would be nice:
The question as to which features to support is determined by what the target audience is. For example, one likely demographic is office workers who would like the ability to seamlessly work from home. Office workers don't usually need 3-D graphics APIs. Another target audience is home/gamers, where 3-D graphics, sound and speed are important.
Potential target markets:
Any designed APIs need to be:
APIs need to be secure, of course. Resources such as video memory usage (aka number of textures) or network usage (i.e. stream bandwidth) need to be resource controlled so that malicious code can't affect other dominions.
APIs need to be simple. Complex routines should be implemented as a loadable package. The API is fixed and cannot change without replacing the VM, so the majority of the complexity needs to be in automatically upgradable code. For example, paragraph rendering would be done in a package, and drawing a glyph would be part of the API.
APIs need to be platform independent so that code is not affected by platform quirks. Loadable packages should ideally not have any platform-specific code.
http://slashdot.org/articles/07/08/28/1425248.shtml
Advantages:
Disadvantages:
A nice font: "Liberation" Sans, released publicly by RedHat. It is a nice compact font (cf DejaVu Sans, which has a lot more characters but is quite wide). It's fairly minimal; it includes Latin, Greek and Cyrillic. IMHO this is a good approach - small file size, stick to relevant characters.
There is a "Droid" font for Google's Andriod platform.
Also, some interesting fonts: Domyouji, Transmute, Venacti, Xenara (search for it on fonts.com).
Some font fixes needed for Squeak:
http://labs.mozilla.com/concepts/
http://noemata.net/nbng/ - random name generator.
Eventually, I'd like a GUI builder like this one: http://www.jformdesigner.com/features/
Internationalisation is important. Languages: http://www.internetworldstats.com/stats7.htm.
Notes that English only gets you 29% of Internet users, and dropping. Mandarin Chinese is going to be huge.