Commit graph

6 commits

Author SHA1 Message Date
Wim Taymans
aa378417c2 interfaces: move proxy API into their own header files 2019-12-11 14:44:59 +01:00
Wim Taymans
95688939bf pw_client -> pw_impl_client 2019-12-11 11:21:43 +01:00
Wim Taymans
d70a47b7fe move proxy implementations in their own file
Rearrange headers
2019-12-11 10:58:51 +01:00
Wim Taymans
8ea78c2e3f pw_core -> pw_context
The proxy API is the one that we would like to expose for applications
and the other API is used internally when implementing modules or
factories.

The current pw_core object is really a context for all objects so
name it that way. It also makes it possible to rename pw_core_proxy
to pw_proxy later.
2019-12-10 18:19:56 +01:00
Wim Taymans
8ddf579cc0 protocol: add flags to protocol marshal
Allows us to to select marshallers for implementation and binding.
2019-11-03 10:21:57 +01:00
Wim Taymans
082463efd0 protocol: add v0 compatibility
For flatpaks we need to be able to support older v0 protocol clients.
To handle this we have:

- the connection detects an old client when it receives the first
  message. It can do this by checking the sequence number, on old
  versions it contains the message size and is never 0, on new
  clients the sequence number is 0.

- We add a new signal at the start of the connection with the detected
  version number. This installs the right version of the core proxy.
  We also move the binding of the client until the hello message is
  received. This way we can have a new client connect (portal),
  hand over the connection to an old client, which then removes the
  client binding again in the hello request with a v0 version.
  There are some changes to the passing of fds in v0 vs v3 which need
  to investigated some more.

- bump version of our interfaces to 3. This makes it possible to
  have v0 and v3 protocol marshal functions.

- Add version number in the proxy. This is mostly automatically done
  internally based on the version numbers the library is compiled
  with. Where the version number was in the API before, it is now
  actually used to look up the right protocol marshal functions. For
  Proxies there is usually just 1 version, the current one. It is the
  server that will support different versions.

- Add v0 compat marshal functions to convert from and to v0 format.
  This has some complications. v0 has a type map it keeps in sync
  with the server. For this we have a static type map with mappings
  to our own v3 types. Pods are mostly the same except for objects
  that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also
  convert between v0 spa_pod_prop and v3 spa_pod_choice.
  Formats and commands are also slightly different so handle those
  mappings as well.
  We only have marshal functions for the server side (resource)
  v0 functions.

- Add v0 compatible client-node again. It's a bit tricky to map, v0
  client-node basically lets the server to the mixing and teeing
  and just does the processing of the internal node.
2019-10-08 23:20:18 +02:00