> I would like to merge proposals. Since you've already
> figured out how to
> get the SwissNumber aspect of a cap: URI into an https:
> URL, and since your
> httpy: proposal would take care of the VLS/VatID side as
> well, I don't see
> any reason why Droplets and E couldn't agree in the same
> httpy: URI format.
>
> There would then be the matter of the handshake: Is the
> designated object an
> E object responding to Pluribus requests or a Droplets
> object responding to
> CGI queries? However, rather than encoding this in the URI
> (cap: vs
> httpy:), I'd rather find a way to do run-time negotiation that's a)
> compatible with both of our constraints, and b) facilitates
> our future
> message-level interoperability.
If the end goal here is to be able to pass a Droplet URL to an E program, and have that E program use that URL as if it was a cap URI from another E Vat, then I think going through my Droplets CGI interface is the wrong approach. The CGI interface is just something that I have so that dumb web browsers can play. The fact that this interface uses capability URIs that are starting to look more like E's URIs shouldn't trick us into trying to push Pluribus through a CGI interface. Why would we want two server programs to communicate through CGI?
I created the Droplets CGI interface so that web browsers could work with an Acid database. To let E Vats work with an Acid database, I would add another, separate interface. There's no reason why I can't have a Pluribus interface and a CGI interface both simultaneously talking to the same Acid database (in fact, the database is designed to do this). Whether this Pluribus interface is just an interface, or a full fledged E Vat, persisting to that Acid database, is an issue that needs more exploration (and some funding).
> Speaking of which, in an earlier message you proposed to
> create an XML
> encoding of E parse trees. As you can tell from recent
> traffic, this is
> more relevant now than ever. Anytime you have a mapping to
> propose...
Why is it that the people without anything interesting to do have all the funding and employees?
It's on the list...
The new XML stuff looks good. Certainly a lot more compact that the SAX code that I had to write in order to be able to parse my Cistern init files. If most of the work gets done in Java (for speed), then I think this could be a real drawing card for E. To that end, you might want to revamp the tone of your essay before looking for new recruits. XML buffs like to think they've got something simple and elegant. Telling them it's barely useable is not a good intro. (However true that may be.)
Tyler