On Sun, May 24, 2009 at 3:01 PM, Stephen Guerin <stephen.gue...@redfish.com> wrote: > And, if we were to make our own, should we start with a REST-like protocol > <http://en.wikipedia.org/wiki/Representational_State_Transfer> supplemented > by server-side javascript or other such animal?
It seems that RESTful use of HTTP could give a good starting point. GETing a base URL could yield a human-readable (HTML) page describing an interface and how to use it. Requesting other representations would allow publication of a variety of forms (e.g. RDF, IDL) for describing the interface in machine-usable terms. This should provide a way of "discovering" the capabilities of an "object", as Kay described. Clearly, URI addressability is key, but that's a core idea of REST anyway. Of course, any server-side implementation choice would be indistinguishable from the client's perspective. You could start with things like PHP or servlets using Java, Scala, Ruby, etc. Lately I've been considering the possibility of creating "actor machines" that could run in a PC virtualization environment (Xen, VMware, etc.). >From the network, these machines would appear no different that any other web/app-server. Internally, I would take advantage of fine-grained concurrency, safety and scaling properties of actors. What's unclear to me is what you see as next steps. It seems to me that any "Universal Interface Language" would have to start with some bootstrap "language" that could be used to discover enhanced capabilities. Doesn't HTTP/REST define an adequate bootstrapping language? If so, the extended language is anything you can describe in your human-consumable initial response, and potentially some corresponding machine-consumable resource (interface) representation. ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
