[General] [Ann] Lively kernel 0.8 is out!

[Mark Miller]

On Feb 6, 2008 5:44 PM, ALT Mobile DEV <dev at altmobile.com> wrote:
> I think that there may be some confusion as to the intent of LK...
> perhaps mine. Despite Dan's hallowed past, LK does not intend to
> create a new runtime/VM. LK's stated intent is to program the browser
> using the browser's environment sans plug-ins (if possible). "Zero" as
> in zero install. So that's the browser's JavaScript with a few 3rd
> party libraries such as Prototype.

Hi Zaid,

I believe we have the same understanding, but there may be a minor
terminology issue. Certainly, LK seeks zero install, and using the
browser environment as is sans plugins, just as you say. Caja also
seeks these attributes.

However, it may be more slippery than it appears whether either LK,
Caja, or indeed any comprehensive JS library constitutes a new
runtime/VM. All create a new programmable level of abstraction on top
that provided by the browser. To the extent that this new level of
abstraction seems self contained, so that one can use it without a
detailed understanding of how it is mapped onto the browser's
platform, it does, in effect, a new platform/runtime/VM. But whether
or not LK or Caja should be described in this way, both LK and Caja
would benefit if LK were written in the Caja-compliant subset of
JavaScript.


> Please correct me if I'm wrong but the most successful implementation
> of Caja is on Google's servers to provide a sandboxed runtime for
> widget/gadget execution. The Apache implementation seems to follow
> this server-side pre-processing approach.

You are completely correct today, and you are mostly correct for the
foreseeable future: The full Caja translator is written in Java, not
JavaScript, and is too large to consider downloading to the browser.
As a result, Caja itself cannot support the LK style of self-contained
live programming environment within the browser *for Caja code*.

To address these very kinds of concerns, we have defined a small
subset of Caja called Cajita. Cajita is no less useful, expressive,
convenient, or secure a programming language than Caja. However, it
leaves out so much of JavaScript that one would only recommend it for
new code. Caja is a much larger subset of JavaScript in order to be
friendlier to old JavaScript code. Cajita is sufficiently small that
we expect to port the Cajita->JavaScript portion of the translator
into Cajita, in which case we can support live programming (and eval)
of Cajita code safely, purely within the browser.


> So unlike in the Smalltalk and Java worlds where you build almost
> everything from scratch, LK has to rely on other technologies for its
> success since at it's core LK is just a JavaScript library with an SVG
> UI toolkit (and some cool networking stuff in the future).

Of these other technologies, how much of their code could be within
the scope of LK's browser system, and subject to live reprogramming?
Within the constraints of the existing browser platform, I think the
answer must be essentially none. The code that appears in LK's
browsers will almost all be new code anyway. Were the code in LK's
browsers in Cajita, and were we to realize our fantasy of a
browser-side Cajita translator, then the LK browsers could eval it
live, as LK currently does for JS code. Since Cajita (like Caja) is a
subset of JavaScript, this can be explored today, without waiting for
Cajita to be ready.


> I'd appreciate any corrections to my understanding of LK and Caja
> since as a mash-up vendor we are exploring Caja's potential and are
> already developing for LK.

Glad to hear it; both are wonderful news!


> thanks for making this an open forum.

You are quite welcome. Openness is always my first choice.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM