Grand Unified Theory

From Vexi

The Javascript engine in Vexi is based on the paradigm the "Grand Unified Theory of everything" [GUT].

Expanation by Adam Megacz

Adam Megacz once explained the GUT on the XWT mailing list (thread archived here). There are a number of references to features which are either named differently or done differently, but the core concepts should still apply.

Let me try to formalize what David posted and extend it in order to
pull together sandboxing (like Java classloaders), runtime xwar
loading, reflection, and theming into a single, unified concept.

Resources

   So there are these things called resources.

   They're really just plain old javascript objects; the only thing
   that's special about them is that they are the only objects you
   can pass to xwt.overlay() [we'll get to this in a second].
   Different kinds of resources behave in radically different ways,
   so it's important to remember that they don't have much in common
   except that they're all javascript objects.
   
   You can load a resource from a URL like this:
   
      var resource = xwt.load(url);
   
   It's important to seperate *transports* from *content types* here.
   Any arbitrary combination of one of these transports and one of these
   content-types should be supported:
   
     transports: file, http, https, jabber
     content-type: xwar, png, gif, xml, bytestream, xmlrpc

   Note that xmlrpc is a content-type, not a transport.  It runs on
   top of http(s).  Subproperties of an xmlrpc object are the methods
   to be invoked on it.  Subproperties of an xml object are defined
   in Appendix F of the reference.  Subproperties of an xwar object
   are the subdirectories and files within the archive.  The others
   should be pretty self-explanatory.
   
Resolving names to resources

   You will often be restricted to ascii text strings in certain
   places where you would like to specify a resource.  Such
   situations include:

       - XML element names in templates (children of <template/>)
       - Attribute values for the properties "image" and "border"

   Any time you use ASCII text to identify a resource, one of things
   happens:

       1. If the string contains ://, it is treated as an URL and
          passed to xwt.load().

       2. Otherwise it is treated as a resource path (delimited with
          dots) relative to the root of your resource tree.
   
   The <import/> element essentially gives a list of alternate roots
   to search during the instantiation of that template.  It's like a
   temporary call to xwt.overlay(xwt.root, <foo>) [yes, yes, we're
   going to get to that].

Theming and overlays

   The xwt.theme() function will be deprecated and replaced with
   xwt.overlay(source, dest).  Both source and dest must be resources;
   you can't call xwt.overlay() on a box, or on xwt.math or anything
   stupid like that.  After the function is called, getting or putting a
   value to any property on source will first get/put to dest, if dest
   also has that property.

Sandboxing

   Your reality is defined by your xwt object.  That's the object you
   get when you type "xwt.*".  All text-to-resource resolving is done
   relative to xwt.root (which is superficially similar to
   xwt.static).

   You can create alternate realities by cloning your xwt object like
   this:
   
      // the new xwt object's xwt.root is initially null; it can't
      // "see" any of our resources
      var new_xwt = xwt.clone();
   
   You can load potentially malicious code (ie code that might try to
   steal information from password boxes, etc) like this:
   
      // load the xwar as a resource
      var malicious_xwar = xwt.load("http://badhacker.com/evilstuff.xwar";);

      // overlay it onto the root of the other universe's namespace
      new_xwt.overlay(new_xwt.root, malicious_xwar);

      // jump through the wormhole into the other universe
      var template = new_xwt.root.main;

      // note that we don't have to type new_xwt.newBox() here
      xwt.newBox().apply(template);

   No piece of code that came from evilstuff.xwar will ever be able
   to obtain a reference to any object that belongs to the
   preexisting xwar, unless the preexisting xwar passes the reference
   into the alternate universe.  It's like a one-way wormhole -- the
   first universe holds a reference to the second universe, but the
   reverse is not true.

   Important point: templates and functions are bound to particular
   xwt object instances.  Boxen and threads are neutral -- they're
   not affiliated with any particular universe.  When you obtain a
   reference to a template by walking down xwt_object.root...., the
   template object you get back is bound to that xwt_object.  Any
   functions created as a result of applying that template are also
   bound to that xwt object.  Any code within those functions which
   references "xwt" will get the bound xwt object.

   There will also be a facility for overriding methods on the xwt
   object to trap (and redirect) things like xml-rpc calls, thread
   creation, etc.  This makes XWT capable of self-virtualization
   (much like the JVM, PowerPC chip, or User Mode Linux OS).

 - a