XEMBED: Preventing focus loops

[Owen Taylor]

On Fri, 2003-08-22 at 03:11, Andreas Aardal Hanssen wrote:
> On Thu, 21 Aug 2003, Owen Taylor wrote:
> >What the spec currently says about the protocol version is:
> >_XEMBED_INFO.version:
> >(...)
> >XEMBED_EMBEDDED_NOTIFY.data2:
> >(...)
> >        The protocol version in use (see the description of
> >        _XEMBED_INFO).
> >Which defines pretty clearly how it is set. But what does it mean?
> > - Is a client/embedder allowed to send messages to the other
> >   end that are not defined in the protocol version in use?
> >   Are clients required to ignore messages they don't understand?
> 
> What practical use does it have for the client and embedder agreeing on a 
> minimal version number? We have two interesting cases:
> 
> 1. A new client speaking to an old embedder
>    a) The client sends messages to the embedder that the embedder
>       does not understand, and the embedder ignores all unknown
>       messages.
>    b) The client knows the version of the embedder, and only sends
>       messages that the embedder understands. The embedder complains
>       about any unrecognized messages.
> 
> 2. An old client speaking to a new embedder
>    ---"--- as for (1)
> 
> There is, from what I understand, a strong requirement of backward
> compatibility in XEmbed. In the sense that both the client and embedder
> may implement newer or older versions of the protocol, and still work
> together (although not necessarily optimally). In that sense, I suggest
> that
> 
> 1. Unknown messages are discarded and unknown fields ignored, since from
> an end user's stand point, it's not really interesting to get warnings.
> Especially if the embedding works. If embedding doesn't work, then there's
> a bug in either the client or the embedder, and the maintaining party will
> treat it as such.
> 
> 2. It is expected that messages that may not be recognized by the peer are
> sent regardless of the version mismatch. If the peer adheres to (1)
> things should work fine.

I'd agree with this analysis.

> A big however must be that both embedder and client implement the _exact_
> protocol, and never (1) send undefined messages with type _XEMBED, never
> set undefined properties on a window with type _XEMBED_INFO, and never (2)  
> extend the protocol by using unused fields in defined messages.
>
>Defined and undefined refer to the protocol version in use.

I'm not sure I understand how this last paragraph correlates with 2 -
first you say that "messages... are sent regardless of the version
mismatch". Then you say clients must never send undefined messages
where defined refers to protocol versionm in use.

Also, note that the the requirement is more precisely, not that:

 - Every message that a embedder/client sends must be defined in
   the spec

But rather:

 - Every message ID used must be reserved in the spec so that it
   cannot be confused with another message.

As an artificial example, we could for example, say in the
spec that message IDs from 0xf0f00000 - 0xf0f0ffff are reserved
for Qt-specific extensions, and then Qt could send them without
needing to define each message in the spec.

Another thing to think about in this context is Denis Mikhalkin's
proposal for allowing a list of XEMBED capabilities/extensions:

https://listman.redhat.com/archives/xdg-list/2003-March/msg00071.html

If we did something like that, it allows a somewhat more free-form
extension of the protocol. We could even do dynamic assignment
of message numbers:

 0x00010000 - 0x0001ffff: messages for first extension
 0x00020000 - 0x00020000: messages for second extension

Though there is some definite question of how fancy it makes sense to 
get here.

Regards,
						Owen