XEMBED: Preventing focus loops

[Andreas Aardal Hanssen]

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.

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.

>But I don't want to force implementors to clutter up code with:
> if (version >= 1)
>   flags |= XEMBED_FOCUS_WRAPAROUND;

Agreed, this is terrible. It adds to the risk of making programming
mistakes, and makes the flow of control unreadable. :-) I hope we can keep
the protocol backward compatible without any of the peers taking this into
consideration.

Regards, Andreas

-- 
Andreas Aardal Hanssen