About this project
[1] Dan Ingalls, Krzysztof Palacz, Stephen Uhler, Antero Taivalsaari, Tommi Mikkonen. The Lively Kernel -- A Self-Supporting System on a Web Page. In Proceedings of the Workshop on Self-Sustaining Systems (S3) 2008, Springer LNCS 5146, pages 31-50, Potsdam, Germany, May 15-16, 2008, Springer [2] EcmaScript 5.1. http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262%20edition%205.1,%20June%202011.pdf [3] Douglas Crockford. 2008. Javascript: The Good Parts. O'Reilly Media, Inc. [4] Marijn Haverbeke. Eloquent Javascript: A Modern Introduction to Programming. No Starch Press, 2011. http://eloquentjavascript.net [5] node.js. http://nodejs.org [6] EcmaScript Harmony modules proposal. http://wiki.ecmascript.org/doku.php?id=harmony:modules#modules. As of 02/20/2013 [7] CommonJS module system. http://wiki.commonjs.org/wiki/Modules/1.1. As of 02/20/2013 [8] AMD module system. http://requirejs.org/docs/whyamd.html#definition. As of 02/20/2013 [9] Jens Lincke, Robert Krahn, Dan Ingalls, Marko Röder, and Robert Hirschfeld. The Lively PartsBin: A Cloud-based Repository for Collaborative Development of Active Web Content. In Proceedings of Collaboration Systems and Technology Track at the Hawaii International Conference on System Sciences (HICSS) 2012, Grand Wailea, Maui, Hawaii, USA, January 4-7, 2012, IEEE Computer.  [10] The Java Tutorials - Managing Source and Class Files. http://docs.oracle.com/javase/tutorial/java/package/managingfiles.html
We begin with an atomic concept that is simple and general: simply a unique ID, and a time of creation. The time is a unique ID itself, and we might want to combine these two things. With nothing else, this is a pretty boring thing, so we'll add text to it like a "sticky note", arguably the most general atom in the space of personal information.
What's the idea here? To construct, in several simple yet general steps, a useful information environment. I imagine the process taking not much more than an hour in a Vi Hart-style progression, and not involving much more than 2000 lines of code.
References
Scoping for code and dependency encapsulation
By default, all JS code is executed in the global scope. For example, when evaluating the expression Object a name lookup for "Object" happens in the global scope object (which referes to itself in browser JS runtime environments with window). The only mechanism in JS to create new scopes are functions. When code is executed in the context of a function body, names bound by local variables of that body as well as function arguments will have precedence over other bound names in outer scopes in the object lookup. This has very practical consequences. Suppose certain code depends on a specific version of the Object object. Inside a function the dependency can be replaced:
This has high relevance in a system such has the PartsBin [9]. Parts are persisted objects that are published in an object repository (= PartsBin). Parts can contain both data and behavior. Although Parts can include own code definitions, it is not practical to persist all their code dependencies with them. As an example consider the car below. The car object itself defines a #drive method. When the object gets published this method will be stored alongside. However, the car also is an instance of the class lively.morphic.Morph. Since #drive uses the morphic interface internally it depends on that interface internally. An environment that wants to use the car Part will have to make a version of lively.morphic.Morph that implements that interface accessible to the Part. Since there might be other Parts/objects with differing dependencies, multiple versions of that class might need to be accessible for them. The above mentioned scoping approach can be used to make multiple dependencies available.
Side note: Using closures / function scopes for encapsulation and avoiding global name bindings is considered a "best practice" for writing JavaScript code and heavily used by JS libraries to avoid name clashes [3,4]. Similar to the LivelyKernel module system, the AMD module system [8] uses this mechanism for dependency management. The EcmaScript Harmony module proposal [6] provides a module / export / import syntax that can be seen as syntactic support for defining modules. The node.js module system [5,7] takes things one step further in that modules do not only define a new scope but also create their own execution context in wich the global object is unique. With this approach inter-module dependencies should be made less likely.
Function / module scopes, reflection, interactivity
- Lively Kernel -- global objects make reflection, runtime gradual code development simple. - Reflection capabilities of JS do not provide introspection / modification of function scopes, locally bounds objects! - similar problem: - Persisting closures - Debugging JS code
Proposal
Libraries, embedding applications, providing multiple versions of code: - NewSpeak-like "platform" dependencies (platform object provides dependencies, injected into modules) Enablign reflection / interactivity: - provide a reflection interface for objects bound in function / module scopes - Code preprocessing to "lift" plain source code to code objects before making them available in the runtime - implement via code rewrite / inject into source code
The model above intents to show how a Lively runtime integrates different applications that require the same modules/code entities loaded in different versions. To enable such an behavior, modules/code entities could be stored alongside parts in object repositories such as a PartsBin. A PartsBin then also fulfills the role of a source code database and no distinction between objects and source code as it exists now would be required. - meta system that manages (versions) of modules - what is a module? a group of code entities such as classes, methods, objects? A single code entity?
The simplest thing
Any sticky note can have properties added to it to be more useful as, eg, a calendar item, a contact item, or an email. Some properties are atomic, such as a tag "family", and some may have associated values such as "date" for a calendar item.
Properties
Example: Given the module name lively.morphic.Core and the root URL http://localhost:9001/core/ The file mapping of this module is http://localhost:9001/core/lively/morphic/Core.js (This can be computed by evaluating module("lively.morphic.Core").uri()).
Module versions, source database, and the PartsBin
File-based modules, as introduced above, which include class, object, method, and function definitions work well for conventional applications that are based on modules from the same location. In the context of a web application they enable dynamic loading and code structuring. However, applications that require objects and behaviors being loaded from multiple sources or versions do not fit well into this model: - namespaces exist but a single namespace has a global identifier - i.e. multiple versions of a namespace/module cannot be represented - since the global identifier is also used for a mapping to resources (directories/files) and also this is based on a global naming scheme, representing modules from different locations is not possible.
This shortcomings make it hard to build applications that are based on fine-granularly combining objects/behaviors from multiple sources. Ideally, parts and modules should be based on the same concept. If both are entities stored in an object repository such as the PartsBin and could similarly be loaded into Lively worlds without causing name or version conflicts applications such as this could easily be constructed:
Build Your Own Information Environment