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

[ALT Mobile DEV]

Hi,

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.

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  
browser programming.

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).


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.


--Zaid

ALT Mobile

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
>> JavaScript implementations do not support the ability to extend host
>> objects.
>
> 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
>> classes and class inheritance in JavaScript (the .subclass() method
>> 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
> JavaScript programmers, still Smalltalk-like, and adequately friendly
> 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
>>        Function.showStack()
>> 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
>
>    Cheers,
>    --MarkM
> _______________________________________________
> General mailing list
> General at livelykernel.sunlabs.com
> http://livelykernel.sunlabs.com/mailman/listinfo/general