Re: MCP experience story

• Date: Tue, 17 Oct 1995 13:09:12 PDT
• From:
  "Ivan R. Judson" <judson@mcs.anl.gov>
• cc: Andreas Dieberger <andreas.dieberger@lcc.gatech.edu>, moo-cows@parc.xerox.com
• In-reply-to: Your message of "Tue, 17 Oct 1995 11:12:24 PDT." <Pine.3.89.9510171339.B29173-0100000@unixs1.cis.pitt.edu>

> > One last thing was to do (so far). When my client logs in it does a
> > 
> >   @edit-option +local
> > 
> > in reply to the #$#mcp version: 1.0
> > So far so good. Only when I log in next using a line-based client, the
> > +local is still valid. Therefore this should be reset automatically, I
> > thought. Here is what I did:
> > 
> > In #6:maybe_really_disconnected there is a fork statement that transfers a
> > player home after a certain amount of time. There I put in a line that
> > resets the edit-option:
> 
> This is actually a fairly good idea if the client you use automatically 
> sets the option.  A more realistic option for moos with other clients 
> would be to leave the edit-option as it is and have some per-session 
> override that could be done by the client.  I think I'll look into more 
> flexible edit-options on JHM.
> 
> > I hope somebody finds that useful - if not, sorry for wasting bandwidth
> 
> Well, at the least it might have spurred some progress.  :)

Another possibilitie is to use something along the lines of a 'form'
structure, which should ideally be initiated by the client.

Then initial connection would look something like:

< Welcome Message >
co user pass
<| Authentication (assume it worked) |>
[client to server:]  #$# get-client-options-list $auth_key
[server to client:]  #$# client-options-list $auth_key type: form id: 1213*
[server to client:]  #$# 1213 option: <name> values: <v1>|<v2>|<v3>
[server to client:]  ...
[server to client:]  #$# 1213 done
[client to server:] (either a filled out option list which can be
	created by default dotfiles or querying the user, or a negative
	response all-together, which means 'I don't understand anything you're
	saying')

This seems to me to be more robust, the only deficit immediately
obvious is the apparentproblem of a null response to the options form,
which could in all reasonableness be the +equivalent+ of a negative
response, as the local convention would have it.

The more robust the form-content information is the better this option
could be, however most options are either on or off so it's not clear
to me that spending alot of time building an 'option description
language' would be worthwhile.

At any rate, the problem of options is something that won't go away
for a good long while yet, but in the end, I suspect a
client-initiated solution is the best.

--Ivan, rambling on from too much sudafed...

• Re: MCP experience story
• From: James C Deikun <jcdst10+@pitt.edu>

• Prev: Re: MCP experience story
• Next: Re: MCP experience story
• Index: MOO-cows
• Thread: MOO-cows