This technique enables you to have a truly dynamic web page that never needs to reload and can change dynamically based on external content. The external content can trigger changes in your current page. In this way the page becomes more of a view or channel rather than the static pages we are used to.
We'd like many of the wiklets to be able to contain applicational content similar to dialog boxes; collections of functionality. The layout and integration of functionality with content can be achieved with the current templates/variables/parser-functions way of working, with CSS being used for the overlayed style aspect like usual.
# The current way $wgServer?title=Foo&live # New way $wgServer?content=((:Foo|bar=baz}}
There will be two actions which will be implemented by the livelets extension instead of the current live query-string item. The first is naked which means to return the fully parsed HTML content of the request, but not wrapped into a skin. The second action is plain which also returns the naked content, but it is returned after the templates and parser functions have expanded, but before converting to HTML.
Another MediaWiki feature comes out of the woodwork! I came across a section in the manual called parameters to index.php, which shows that MediaWiki already supports the actions we need.
- render: Using action=render has been available at least as far back as 1.6 and replaces the necessity for action=live in the livelet extension.
- raw: The usual action=raw request comes with some extra parameters, some of them have been commonly used, such as gen and ctype, but another very useful one is templates=expand. This can used by bots requesting code articles or lists etc, it expands the templates but returns the content before parsing any wikitext into HTML. Category links will still be included though because they're processed along with normal links (categories should have been parser-functions I reckon).
- ProcessMessage (update properties or content of a livelet by id - create new livelet if id non-existent)
All the supported input types can easily be made from templates and have various parameters passed to manipulate their prperties and id etc. Forms are then just collections of these.
If an id is sent in the query string, then the response will be returned to the livelet with that id (this could support lists of id's too for one-to-many communications), or will create a new livelet if the id is zero. If no id is sent, the response will be directed to the livelet that requested it.
Some examples of events that would be communicated back to the server.
There must be a tree of id's which are navigatable by class, so that each running wiklet can address items within it by class. The items id (guid) is then used by the server to communicate results when ready.
Full P2P can be done with standard browser
It would be useful to allow all the SWF's on a single machine to communicate together to designate one of them to communicate with the server. But if we had that capability, it would make sense to allow each SWF to be connected with a different "server" (peer), and to abstract this to allow the opening of arbitrarily many asyncronous connections