SiteBrowser

SiteBrowser is a component of the Unnamed Grand Project. It presents the user with an interface like a web browser.

Random ideas for components:

• Back button, Home button, history and navigation.
• Clock.
• Desktop-like area with user's "favourites" / bookmarks / desktop items?
• Key management? Somehow?
• Location bar.
• Site authentication bar?
• "Review this" widget?
• Tabs, for each page. This may be better done using bookmarks.
• Volume (audio) control
• Full-screen button.

Suitcase 

Each user would have a "Suitcase" which is a globally available window accessible by pressing a key on the keyboard (maybe ESC). This would be the replacement for the Start menu, task bar and desktop metaphors of other OSes. It would contain widgets to control basic functions of the local console (start up / shutdown, volume, clock, etc). The bulk of the "suitcase" window would be a tree of "Desktops" with windows as children.

Each Desktop would represent a particular task. Desktops can be navigated by a key combination ("CTRL+ALT+up and down arrows maybe?). Desktops are persistent and distributed; the user can move to another machine, authenticate himself, and the user's suitcase and desktops (complete, with window locations, etc) will be available. Desktops can contain windows, objects and folders (containing more folders and objects). Objects are opened in a window which shows a Site, which shows the opened object. Folders are objects that contain other objects.

Each window shows a Site.

The suitcase would contain a lookup utility to find Sites. Objects would be represented by Sites (because a Site is needed to visualize anything on the screen; a default site such as an "inspecter" would be used for objects with no site implementation). The lookup utility would be kind of like DNS or a search tool, or something.

Users can drag and drop windows (Sites) to and from the suitcase, and between desktops. Sites can be open on two desktops at the same time. 

Client installation

The user downloads a client. When the client first "boots", it loads the SiteBrowser code from a remote site. This lets the SiteBrowser's implementation be modified at a later date.

The client would be SecureSqueak.

The client only implements a simple Canvas and event handler. The SiteBrowser code is given full access to the system, and after initialising, is responsible for managing dominions and implementing features such as navigation, user management and virtual consoles.

The client would have a simple REPLServer (i.e. command line) built in which is accessable through a key combination (alt-. maybe?). This lets the user have complete control over the local system.

Location / Lookup bar

This is where the user enters something like a URL. Entering plain words here will present either search results, or take the user directly to that registered site. Perhaps there could be two buttons - one for going there, and one for searching. The text field could also have other uses, e.g. to search local objects.

Once a user has found a page, that user would typically add that page to their bookmarks (suitcase) for future use.

Site hosters could register keywords, e.g. "flowers". This would bring the user directly to their page.

People can register their sites for authentication (address verified, etc), which would also add a "review" link for that site. These sites would come up first in the search bar.

Keywords could be geographically separate. This could be by distance, or by country. If the keyword isn't registered locally, the search continues elsewhere.

Site hosters could initially purchase a keyword for a period of time. If a keyword is contested, it could be auctioned to the highest bidder for a period of time.

For example:

Keywords are registered for a trivial fee - e.g. $0.20/week. Anybody can register them. Anybody can register a keyword for a certain period of (pre-paid) time by putting a bid on it. The highest bidder becomes the default site, the other bidders have their sites come up in search results in order of their bids. Bids are public.

For fairness, the owner of a keyword has a period of time (5 days, taking weekends/holidays into account?) to respond to a hostile bid. After that grace period, the highest bidder then becomes the new owner of that keyword.

BrowserContext

Somehow, each site needs access to various local devices. Each device's API would be specified by... a version number? Perhaps the package linking could take care of this?

• The root canvas of the display. This is different for each site, making package linking interesting.
• Sound (speakers at 7.1 or more, microphones, other inputs, ...)
• Printers
• Mass storage (#filesystem1), access to the filesystem.
• Local dominions
• Other devices: webcams, scanners, joysticks, tablets, [multi-]touch screens, network (e.g. HTTP or TCP stuff somehow?), audio cdroms, ...
• Plug-ins such as OpenGL, video-conferencing, media codecs, fast image operations, ...

Each Site would also have some utilities:

• A logging service.
• Authentication of the user.
• A messaging or alerts service to tell the user stuff (with spam protection).
• Clipboard, drag+drop operations - provided through the Canvas API.
• Email service to make and send an email.
• Able to open... a web-browser on a URL???
• Some way of bookmarking the site. Bookmark meta-data would include the name, a categorisation (in the sense of dmoz.org), a page description, keywords for searching through bookmarks. Bookmarks would be icons in the user's "suitcase".

Lifecycle events

These events are received by a Site when particular things happen. These events will also be sent to every site in the user's suitcase even when they are not open. Messages often have their own

• Log in: this will happen every time the user logs in again and the site is presented to them. It may happen multiple times on the same instance because instances of Site are persistent across restarts. This is distinct from opening the site.
• Log out: when the user logs out.
• Open / Close: When the user opens and closes a window containing that Site.
• Idle: When the user is away ("AFK") for, say, 1 minute.
• Screensaver: When the screen saver starts up.
• Lock: When the user locks the screen.
• Unidle: When the user is back again.
• Suspend, hibernate, shut down: When (actually just before) the computer does each of these. Each of these has the corresponding wake up message. There would be a contract stating how much time the Site has before it is deactivated.
• Network disconnect: When the network is no longer available. This might require more thinking; what actually happens is a network split.'
• Dominion events, such as "dominion deallocated from this machine" (aka "get out of this machine now"). 
• Need disk / CPU / etc: for each resource, when that resource is under heavy use. This is a polite request from the local machine to reduce resource usage, e.g. by deallocating cache or stopping background threads.
• Device connect / disconnect, e.g. when USB disks, scanners, cameras, etc are connected.
• Lid open / closed - for a laptop lid.