XEmbed, adding second client to same embedder

[Owen Taylor]

On Fri, 2003-08-22 at 08:45, Andreas Aardal Hanssen wrote:
> Hi, list. :-)
> 
> When an XEmbed embedder detects a client (through ReparentNotify or
> CreateNotify), the message XEMBED_EMBEDDED_NOTIFY is sent from the
> embedder to the client, as defined in the protocol.
> 
> There seems to be a missing message (or rationale) in the protocol for the
> case when the embedder does _not_ wish to embed the client. There can be
> several reasons for this case; the most obvious being case where the
> embedder already has embedded a client.
> 
> There may also be other cases where the embedder does not wish to accept a
> client, but I can only construct a few unlikely examples myself (the
> embedder only accepts clients of a certain kind, with certain properties).
> 
> My implementation immediately reparents the second client window to root,
> and then continues operation as if nothing happened. The client would then
> handle this as if the embedder had shut down, and it might (depending on
> the specific client) issue a warning, or otherwise react accordingly,
> although the assumed reason for the shutdown is not right.
> 
> I'm thinking of a message such as XEMBED_CLIENT_REJECTED, where data1 has
> flags that give more information about the reason for the reject. This is
> thinking out aloud, but I think it's good if this case is mentioned in the
> protocol specification.

Hmmm, I sort of consider embedding two clients into the same embedder
a similar problem to trying to embed a client into some window that
isn't an embedder at all.

Since the XEMBED protocol doesn't provide sender window in the messages,
there is no way to support two clients, so it's always an error.

So, the "higher level protocol" that is used to set up the embedding
needs to make sure it never happens.

I think your strategy is a fine way of handling things, and perhaps
should be mentioned in the spec that something a robust embedder may
wish to do. But I don't see any reason to require it or to add extra
information about what went wrong to the protocol... the most efficient
way of  letting people debug the situation is probably to just print a 
warning to stderr.

Regards,
						Owen