Re: question about supernova mcp spec

[Michael Brundage <brundage@piaf.ipac.caltech.edu>]

On Fri, 8 Aug 1997, Erik Ostrom wrote:
> What are #$#client-get/set/value intended to be used for?  I'm just
> puzzled by them.  Also, are these property values per-site?
> Per-connection?  Do they persist across reconnects?  And so on.

At the moment, I'm using them mainly as a way for obtaining client 
properties such as version, username, linewidth, etc. from either the 
client or the server.  Some are static, unchanging properties, and others 
are set on a per-connection basis.  Frankly, it's kind of a kludge, and 
I doubt it will last beyond the initial development phase.  Jupiter had 
a system for storing properties on windows and widgets that was useful 
for awhile, but increasingly less so as the system became more 
fleshed out, more useable and robust.

Like most of our other client-* messages (such as client-redirect), these 
aren't really part of our MCP proposal; they are just something that we 
reserve in the Nova dialect of MCP our client speaks, and are a part of 
what constitutes the "core" client feature set for Supernova.  They have a 
certain "blessed" status, both in terms of what they can do (e.g., 
upgrading the client, setting global security values such as the 
authentication key or encryption scheme) and in how they are implemented in 
the actual code.

This also touches on another point you've brought up, namely client 
upgrading.  We have built our client in such a way that no features are 
considered fixed parts of the client, but we do not yet do client 
upgrades.  There are so many other things to be done that it will be 
a month or more before I get to it.  I'm not sure how I want the protocol 
for that to be structured; like you said, it's all a kind of experiment.  
Dave Nichols and I talked a little about being able to extend the widget 
set in Jupiter; apparently it was something they wanted to do, and to 
allow users to create custom widgets from pre-existing ones, but if they 
ever got around to it, we never saw it.  We're working on a totally 
dynamic widget set with core components built in but anything else 
downloaded over the network (from the MOO or elsewhere).  Once I know how 
to do it for widgets, I'll apply those ideas to client upgrading as a whole.

We've looked at Java RMI and CORBA, and at various other RPC schemes.  My 
personal dream is the ability to transport MOO and Java objects 
transparently (or as nearly so as possible) among clients and servers to 
create a truly distributed, networked collaborative environment.  I 
imagine being able to hand a user in one world a electronic business 
card, and that person be able to carry it with them to any world they want. 
For now this is just a dream, but it's a start.

Speaking of dreams, if you all haven't read the Jupiter teams' NII 
Scenarios (I HTMLified it and put it in the supporting documents section 
of our web site), you really should do so.  It's a work of art.

Have a nice weekend,

michael