[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Greetings and comments on MCP 2.1
Anyone else feeling swamped by the deluge of MCP discussion? At least
I'm only 9 days behind... :-)
On Fri, 8 Aug 1997, Erik Ostrom wrote:
> I've got a related problem for you. Suppose I'm writing my MCP-enabled
> client. Suppose, further, that there are some servers that don't want you to
> put up a conventional "MUD" window at all--they want to start with a dialog
> box, or have a special protocol for creating chat windows, or they're just
> tic-tac-toe servers so why would you have a chat window?
Jupiter handled this in the following way: Widgets (GUI components) had
various properties (height, width, font, etc.). Some properties applied
only to particular widgets, and two properties which applied only to
text-edits (viz. Java's TextArea) was MainInput (or MainOutput). A
textedit designated MainInput would direct any text entered into it to
the server (as in-band data); similarly, a MainOutput textedit would
display any in-band text received from the server. (Jupiter was
primarily a UNIX program, and stdout also served both these functions, so
it was possible to run Jupiter through a script or a UNIX pipe, e.g. from
within Emacs).
So that is one possible solution.
> Suppose, finally,
> that I also want to be able to connect to servers that mix MCP messages (such
> as #$#edit) with ordinary MUD interaction, as well as plain old dumb-as-dirt
> TinyMUD servers.
[server options vary per listener]
> It's embarrassing that I don't know the answer to this, but: Did Pavel fix
> that?
Yes. the_listener.server_options is the object queried for things like
the welcome message, connection/disconnect messages, etc., for
connections through the_listener.
> [MCP] doesn't speak to the question "what would you PREFER to do?" Again,
> this is something that we've had no opportunity to get experience
> with; the question "whose audio protocol would you like to speak"
> hasn't come up in the absence of even a single audio protocol to
> decide between.
>
> I guess my suspicion is that, in most situations, this question gets answered
> implicitly. For example, having established that both client and server are
> capable of receiving/sending both RealAudio and StreamWorks audio, the
> question is resolved by the fact that the server sends RealAudio messages and
> not StreamWorks messages. For any interaction that is initiated by one side
> or the other, the initiator gets to decide what protocol is used. And, again
> for the most part, I think as long as both parties speak both protocols, this
> is fine.
It's more than just a matter of file formats; it can also mean feature
sets more generally. After all, one may have
----------------
/ generic set of \
\ audio features /
----------------
/ \
---------- ------------------
/ Somecool \ / An environmental \
\ audioFX / \ sound synth /
---------- ------------------
Both may work as audio components, supporting some basic set of audio
features (play this sound, record that sound). But Somecool audioFX
might have various distortion capabilities, while An environmental sound
synth might be able to synthesize environmental effects (doors closing,
etc.).
When our client doesn't have some capability that the server wants to
use, it will query the server as to where it can find that ability,
download it, and install it (as allowed by the user and other
constraints). So for us, the ability to dynamically add/remove features
and to indicate which features are "preferred" over others, is essential
to the protocol. Of course, I don't think this needs to be in MCP at
all, but it does form a part of the feature and protocol negotiation
proceses. That is, if the client contacts the server, the server responds
"Yeah, I can speak MCP 2.1, but you know the current version is actually
3.0, why don't you upgrade?" then the ability to do that kind of interaction
is a part of our negotiation process.
Cheers,
michael