Let me first emphasize that the key ideas behind the vobject model have 
been shown to be powerful and robust.  The essential concepts of a 
network-neutral message-passing system, associative hyperlinks between 
objects, and the ability to associate of multiple types (behaviors) with 
a single logical vobject have proven their worth.  We have been able to 
rapidly develop a variety of tools culminating in Ter'Angreal, the 3D 
browser, as well as apply the underlying infrastructure to other systems 
such as the Web.

Having thoroughly explored the problem space, we discovered a few things 
that could have been done better.  Thus, the key areas driving s5 design 
are the following:


 1.  Footprint

 2.  Concurrency

 3.  Scripting

 4.  Security


I will discuss each of these ideas in a separate email, starting with 
the first one here.

1.  Memory footprint

The current s4 design has a lot of per-vobject overhead, leading to a 
significant memory footprint.  The development version improves on this 
a bit, but the honest truth is that the implementation was not written 
with memory efficiency in mind.  The s5 design will attempt to address 
in various ways, including attempting to directly minimize the byte 
count of crucial classes and data structures, and by using the 
"flyweight" pattern to collapse identical classes into a single shared 
instance.

In particular, symbols (method names, message fields, types, etc) will 
be stored in a single global symbol table.  This will ensure that such 
strings (which are expected to be used a lot in the system) are not 
duplicated, and has the convient effect of also making string comparison 
a constant-time pointer comparison instead of a linear time compare.

Another method for making the most out of the memory will be the ability 
to load vobjects from persistant storage on demand, and swap out rarely 
used vobjects.  This will allow a site to contain many more vobjects 
than would otherwise fit in RAM.  This 

To reduce the footprint of vobjects themselves, I am introduce a concept 
called "embedded children".  These are objects that appear in protocol 
terms to be independently addressable vobjects that can send and receive 
messages, but are actually stored as a field of another vobject.  This 
emerged from the observation that while it was extremely powerful from a 
design pattern standpoint for properties to be first-class vobjects, in 
s4 this often led to situations where it hundreds of bytes of overhead 
to store even a single four byte integer (for example).  As an embedded 
child, the child vobject is simply a normal data field in the parent 
class, and it falls upon the parent sends and receives messages on 
behalf of the child.

A final goal is to simplify memory management overall.  One significant 
change will be the introduction of a single root to the vobject tree.  
In s4, the site contains a list of every vobject on the site, and the 
site URL + vobject site name acts as the unique identifier for a 
vobject.  Unfortunately, there are two problems with this.  The first is 
that typing "ls" in mesh in the site root on a large site results in it 
printing out 1000s of vobjects to your screen, which is rarely useful.  
The second, more subtle problem is that vobjects are easily leaked by 
orphaning them so that no other vobject points to it but failing to to 
call excise() on it.  In s5 I propose to change this system, to a design 
inspired by the design of the Unix filesystem.  Vobjects will have 
unique, opaque identifiers (which correspond to inodes) that are not 
generally visible to the user, and vobjects will be reqired to be 
accessable from the site root via some path.  Vobjects which are 
orphaned can then be garbage collected.

Other strategies to make memory management easier will include a greater 
emphasis on copying semantics when the amount of memory involved is 
small.  This avoids having to maintain reference counts, and we can keep 
simple data structures on the stack (and in L1 cache?) to avoid 
potentially expensive calls to the heap allocator.

Minmizing the memory footprint is a key goal to ensure scalability, but 
perhaps even more important will be the ability to support concurrent 
and asynchronous processing, which I will talk about in my next email.