[RFC] protocol: Introduce logical surface protocol

[Jonas Ådahl]

On Sun, Mar 17, 2013 at 11:47 AM, John Kåre Alsaker
<john.kare.alsaker at gmail.com> wrote:
> I believe this is the wrong approach. I'd rather see some generic way
> to share any wl_object between clients securely. I don't see a
> transfer of ownership of your handle which means any client and get
> access to it.

There is no particular ownership changes. The surface of the handle
would still be owned by the client created it; it just means it cannot
map it in any way if it is to be used by some other client. The
intention of the protocol is to have two clients collaboratively
manage their surfaces in a controlled manner.

>
> I'd rather have something like this:
> <request name="share_object">
>   <arg name="object" type="object" />
>   <arg name="target" type="int" />
>   <arg name="data" type="array" />
> </request>
>
> <event name="receive_object">
>   <arg name="object" type="object"/>
>   <arg name="sender" type="int"/>
>   <arg name="interface" type="string"/>
>   <arg name="data" type="array"/>
> </event>
>
> One connection uses share_object to send a wl_object and some
> associated data so it knows what to do with it. The target can be some
> unique identifier of a connection to the compositor. The other
> connection receives the object with receive_object. It has the unique
> identifier of the sender and the interface type so it knows which type
> the object it. It can look at the data argument to find out what the
> sender want you to do with the object. If the client doesn't want to
> use the object, it should just delete it.

You can't simply share objects between clients in this way because the
object ids not in a server wide scope. You'd have to create new
objects on the receiving end, and have generic "logical objects" in
some way to associate an object on one client with the original object
on some other client. That will make the semantics complex and quite
hard to specify and implement I suspect. The question of ownership
gets harder as well.

Also, what is your use case for what you are proposing?

>
> There's probably some details regarding interfaces and version that
> needs to be worked out for this to work.

Jonas