Oct. 2nd, 2016

dichro: (Default)
For a project that's a thin layer of glue [sic] on top of user-supplied RPCs, calling RPCs sure is hard. I mean, discovering RPCs is even harder, but unfazed, I added empty art pedestals to the Intangible Gallery, with APIs to allow all and sundry to place objects on them.
Up until a few minutes ago, I thought that the SteamVR overlay keyboard didn't offer symbols, which was going to make typing in URLs for meshes and textures challengingThen I accidentally squeezed the grip buttons on the controller, and voila: symbols appeared! So, yeah, discoverability.

Anyway. I was going to add some icons to the controllers to help with that discoverability thing, but saved it for next version. For the moment, one-way RPC calls are sort-of complete-ish, in the sense that a single-layer record for an RPC request can be populated by the latest version of the client (painfully, using either on-screen or physical keyboards), dispatched, and the text of any reply received is then crudely displayed.

These RPCs are defined using the Avro schema language, which is faintly troubling, since I'm resolutely sticking to protobuf for the streaming presence updates between client and server. I rationalize it like so: the client-server protocol is purely for the machines, supporting what's basically a distributed cache-coherence exercise. Messing with that protocol is unlikely to improve user experience, and it's the highest-volume thing going on, so it's optimized for speed and predictability at the expense of human-readability, ergo protobuf. The client-client protocol, OTOH, is all about personalized tweaks, messing around, version skews, etc; and much less performance-sensitive. Hence, Avro.

Speaking of the client-server protocol, it needs some (compatibility breaking) changes too. Right now, everything assumes that updates are complete, rather than incremental. There's a few useful changes to be made here:
  1. Separate client update type from server update type. Limit the kinds of changes that clients can make via the streaming protocol (ie, only send pose updates).
  2. Provide a registration RPC for clients to call, supplying avatar representation, RPCs offered, etc. (For bonus points, consider whether the server could offer an RPC proxy for the client, and what that could offer (client privacy; positive affirmation of caller presence and VR context))
  3. Nail down semantics of incremental updates.
  4. Be more careful with default values. eg, prefer zero-based rescale (-1, ∞) rather than one-based scale (0, ∞), so that the default does something useful.


dichro: (Default)
Miki Habryn

April 2017


Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 23rd, 2017 02:00 am
Powered by Dreamwidth Studios