[General] [Ann] Lively kernel 0.8 is out!
ALT Mobile DEV
dev at altmobile.com
Thu Feb 7 02:44:20 CET 2008
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
party libraries such as Prototype.
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.
Comparisons to the Squeak's runtime are not relevant since LK does not
propose to create a runtime.
LK has every chance to fundamentally change browser programming. With
Sun almost betting Java's future on JavaFX, I think that LK just might
be the technology to establish Sun as the preeminent browser
programming vendor and finally compete with Flash on the desktop. And
once the Opera desktop engine is fully ported to its mobile browser
next year that will mean that LK becomes the de-facto standard for all
So unlike in the Smalltalk and Java worlds where you build almost
everything from scratch, LK has to rely on other technologies for its
UI toolkit (and some cool networking stuff in the future).
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.
thanks for making this an open forum.
http://altmobile.com/Home.html (web site)
http://web.mac.com/altmobile (official blog)
On Feb 1, 2008, at 5:38 PM, Mark Miller wrote:
> Dan, as you know, I'm eagerly looking forward to seeing a system that
> brings together the strengths of our respective projects. We would
> both like to see lightweight, interactively created active content
> become as prevalent and easily shared as html text is today. As
> section 2 <http://google-caja-discuss.googlegroups.com/web/caja-spec.pdf
> argues, I believe security problems have been the fatal flaw which
> killed most previous attempts at active content. Caja gives us a basis
> for addressing these security problems. Lively gives authors a medium
> for creating active content worth sharing.
> However, your recent message has me concerned that Lively is deviating
> ever farther from programming patterns that can be secured. Before
> making these changes, what thought was given to their possible
> compatibility with object-capability security?
> On Feb 1, 2008 12:59 PM, Dan Ingalls <Daniel.Ingalls at sun.com> wrote:
>> 1. The entire Morphic architecture has been converted to wrap host
>> SVG objects instead of extending them. This was done in such a way
>> as to change almost nothing at the level of most applications. The
>> major benefit afforded by this change is compatibility, since many
> Good. The Caja effort has made the same decision regarding DOM and
> other conventional browser host objects.
>> 2. We have adopted a class system derived from prototype.js ver 1.60
>> and extended with built-in support for serialization and copy
>> constructors. These conventions make it much more natural to use
>> and $super optional parameter).
> The Caja group has been puzzling over the extent to which Caja can
> support the programming patterns that Prototype encourages. Our
> conclusions so far are that Class.addMethods can't be rescued, and
> that Object.extend is problematic at best. OTOH, Figures 7 and 8 of
> <http://google-caja-discuss.googlegroups.com/web/caja-spec.pdf> show
> the recommended Cajita inheritance pattern which seems to have all the
> virtues of Smalltalk's, including even a proper "super", while
> remaining friendly to object-capability principles. See also Figures
> 14 and 15 for an inheritance pattern that's more familiar to
> to object-capability principles.
>> 6. We have the beginnings of a reflective model for execution state.
>> If one sets Config.debugExtras = true, most methods are wrapped with
>> a function that keeps track of the stack with method names *and* even
>> the arguments. This can be tested by, eg, typing
>> in any textMorph, selecting it and evaluating it with alt-d. This
>> should result in the stack being printed to the console with method
>> names and argument values.
> Are you thereby providing ambient access to the ability to reflect on
> one's caller? What security properties do you imagine might survive
> the availability of such an operation?
> As you heard me say at OOPSLA, Squeak-E failed because Smalltalk code
> was not facing a hostile environment, so the Smalltalk community never
> became willing to sacrifice anything else they value for the sake of
> security. I have no argument with that. If that's the right tradeoff
> for Lively, fine. But please make the choice with your eyes open.
> Text by me above is hereby placed in the public domain
> General mailing list
> General at livelykernel.sunlabs.com
More information about the lively-kernel