[Edu-sig] Alan Kay - another one of his ideas

[Yoshiki Ohshima]

  Ian,

> Of course, as these things go it's still relatively crude, and currently 
> hooking things together means lots of crufty-looking scripts.  But then, 
> I think the natural way to hook things together on the web is 
> declarative anyway, and maybe the natural way to think about HTTP is as 
> resources not objects, and I suspect that leads to some substantive 
> differences with Squeak's model.

  There is no single "Squeak's model"; don't worry about that.  We've
been experimenting a few different ways, but we aren't promoting a
single one as the "best" solution.  Anything better than these is
simply better.

> One thing that occurs to me that defines the web is how 
> transaction-oriented it is.  So no *one* person has a hold on any 
> object; everyone actually just gets a browser-local copy of the objects, 
> and may try to commit changes to the server.  This is probably very 
> different from how Squeak works as well.  But, of course, it scales way 
> better because it is so optimized for reading, and it's quite unclear to 
> me if a "better" web is actually feasible from a performance and 
> management perspective (certainly Ted Nelson's transclusion seems absurd 
> given the instability of content on the web that we should now accept as 
> inevitable).

  Alan used the word "OpenDoc" in the keynote a couple of times, and
what he meant was to use OpenOffice's "Open Document Format" as the
common storage format on the web.  One of our experiment is to have
the "local copy" of the content, the user edits it on his local
machine (in a dynamic environment), and the user stores it to the
server when he wants.  This works, of course.  BTW, I wouldn't call it
"transactional"; being "transactional" requires a bit more "theory" on
what should happen when a user want to modify more than one pages "at
once", the activity of the other users, and the rollback (or back
button).  (We wouldn't have to worry about the back button problem in
the web apps, if the entire web was aware of that.)

  Ted's particular implementation of transclusion is pretty bad, but
the idea itself has some good aspects.  We should be able to track the
change in the content, right?

> ...Incidentally, while we were looking at some possible examples people 
> might write in this Javascript system, we'd write something out in 
> Javascript and then look at it and despair that it seemed quite unlikely 
> a non-programmer would ever come up with the right incantation -- that's 
> somewhere where the LogoWiki language implementation could offer a 
> really nice alternative.  Of course, we are just now starting to see 
> reasonable debugging interfaces for Javascript that aren't too heavy or 
> too obscure, and this'll mean giving up even that... :(

  Or, like any other languages, JavaScript might be revised in the
future.  And a browser will be as well.  I think there has been a
discussion on how Python would be included to future browsers like
current JavaScript does.  Think about what such a language should be
like is one of the interesting aspects around this.

-- Yoshiki