01:35 <kentonv> ratmice_, Cap'n Proto messages are strictly trees -- no aliasing / overlapping. So a "slice" doesn't really make sense.

01:52 <ratmice_> kentonv: k, FWIW, i'll explain the scenario, since we are working with trees as well (and looking for a wire protocol to replace an ad-hoc one)

01:54 <ratmice_> the deal is that the trees are ridiculously large, on so the server sends the client essentially a promise for some subset of the list/tree, the client then checks its cache to see if it has it locally, otherwise it passes the index back to the server

01:59 <ratmice_> which kinda happens in 2 places, the client <--> server <--> disk, anyhow, it would be perfect if that were doable via capnproto serialization/promises

01:59 <ratmice_> alas :(

02:20 <mokomull> Looks like both of my "it can't possibly be meant to work that way" from bus1 seem to be fixed :)

13:39 <TimMc> ratmice_: Can capnp address individual items? I remember something about it being able to pipeline (is that right?), so maybe you could ask for a bunch of items that all happen to be a slice...

20:04 <isd> TimMc, ratmice_: You can at least walk down struct fields to get caps without actually sending the struct down the wire, see: https://github.com/capnproto/capnproto/blob/master/c%2B%2B/src/capnp/rpc.capnp#L997-L1024

20:04 <isd> (and there's some comments there about possible extensions).

20:09 <isd> But that's specific to fetching capabilities. It's at present probably too restrictive to use in a turn-key fashion for your use case.