[disc] conflicting packages

[Erik Ostrom <eostrom@research.att.com>]

> It's more than just a matter of file formats; it can also mean feature 
> sets more generally.  After all, one may have

I don't think I said anything specific to file formats.  My claim was
that, in most situations, if both sides of a connection speak multiple
packages that overlap in functionality, the question of which
package to use gets answered implicitly, simply because the sender of
a message gets to decide what the message is.

>  ----------   ------------------
> / 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.).

Right.  So when the server wants you to hear something with
distortion, it will send a message using the Somecool package; when it
wants your client to synthesize environmental effects, it will use the
environmental audio package.  When it doesn't matter, it will use the
basic audio package (and your client can decide what library gets to
handle that).

> 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.

Not necessarily.  If you have an upgrade-and-renegotiate facility,
then I don't think you need to indicate preferences.  Suppose that the
server can send both Somecool and Environmental messages; it prefers
Environmental, but it can make do with Somecool.  The client
understands only Somecool.

So, the server can send a suggestion that the client go fetch
Environmental.  (It doesn't have to say "because I like that better
than Somecool".)  Until the client has done so, the client and server
can continue to communicate with Somecool.  If and when the client has
fetched and installed Environmental, it sends whatever messages are
required to notify the server.  At this point, the server simply uses
Environmental consistently--and again, no explicit reference is made
to preference.