Even lower-level api

[andrewbaxter]

I'm interested in proxying wayland connections and filtering/modifying some requests.

I was poking around with wayland-client and wayland-server and AFAICT this would require:

1. When a client creates an object, create the same object on the server + store together in a lookup
2. Implement Dispatch for all object types
3. On each request to each object type, look up the corresponding object on the other side and use it to send_request upstream

And I think something similar for downstream/events.

Aside from needing to create two objects when no state is required locally, I'm mostly looking at all the boilerplate I'd need to write to do the forwarding. I'm not sure if I'd need to do it for everything that implements Proxy (which is... a lot) but it doesn't seem trivial.

I dug around, and it looks like there's something lower level like client.next_event() but it doesn't appear to be exposed. I basically want something to handle socket setup (for whatever specific socket options wayland requires) and parsing and nothing else. Is there an easier way I can do this?

FWIW I was looking at sommelier but it's quite complex, so maybe this is less trivial than I imagined for other reasons. There's a couple other wayland proxies/load balancers but IIRC they do socket-level stuff rather than protocol-level.

[andrewbaxter]

Ah... digging deeper into the Wayland protocol it seems like this isn't possible. Basically opcodes are relative to the object type, so you can't know what opcode 7 means without knowing what the object it's called on is. This means knowing the full chain of object types (i.e. storing some state for all of them).

That said, I don't see a way to hook into constructor requests for forwarding...

[andrewbaxter]

It looks like constructors are just normal operations on some other object - i.e. there are as many different constructors as there are resource types, and to track state you need to hook into them all... so no macro-based implementation possible?