mnutt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wolcen has joined #sandstorm
isd has joined #sandstorm
<isd>
_habnabit: what do you mean by "general?" If you mean a standard approach preferred by the community, I don't know that there is one.
<isd>
My take would probably be to use a websocket. Maybe a capability URL to determine the bootstrap interface. The rest of the details may depend on what you're trying to achieve.
<_habnabit>
isd, blugh. i was thinking websockets too. but i just wanted to do single-shot request/response. i didn't know how much you needed to negotiate or if it would be possible to do it like this
<_habnabit>
isd, but yes i meant is there a standard agreed-upon approach
<isd>
I don't think there is.
mnutt has joined #sandstorm
<_habnabit>
i guess i expected that there would be a way to serialize the whole of "here is all the pipelining i want done" as an http request and then get a response once it all completes
<isd>
I *think* the protocol makes it feasible to do what you need without multiple round-trips, so it ought to be possible to just POST the whole client-side of the session and wait for responses in the HTTP response.
<_habnabit>
yeah
<isd>
But it strikes me as probably cleaner to establish something that actually does the streaming transport abstraction properly, unless you have a specific reason not to?
<_habnabit>
websockets are very fiddly to configure, and websocket _clients_ are relatively rare
<_habnabit>
i mean, fiddly to configure in the server-side load-balancing end
<_habnabit>
and non-js clients
<TimMc>
Yeah, took me ages to find a non-broken websocket client for Java -- it's assumed you'd be in JS.
<isd>
Fair enough. You should be able to just POST a sequence of messages and then read the responses.
<TimMc>
(Unrelated to sandstorm, just +1'ing the point.)
<_habnabit>
i was really just hoping to find prior art, since i don't necessarily trust myself to get the rpc semantics right
<isd>
Fair enough. I don't know of any, unfortunately.
<isd>
I don't think you should have to dig into the rpc details that much. wrap the request/response bodies in your generic reader/writer interfaces and then start up the usual rpc mechanism, using that as a transport. Just make sure the server doesn't try to invoke methods on anything.
wolcen has quit [Ping timeout: 258 seconds]
<isd>
I've mostly dealt with the Go implementation.
<isd>
What would that even look like? Sandstorm apps are usually full web-apps; you might package something like this with another package as a dependency, but it typically wouldn't be a stand-alone thing...
<mnutt>
I've been thinking it would be cool to provide something like https://parseplatform.github.io/ as a platform on sandstorm and try to encourage mobile app developers to use it with their mobile apps. It would probably be difficult to sell mobile app devs on it as compared to centralized hosting, though.
<mnutt>
(speaking of databases in sandstorm)
<Guest43253>
btw looking at the website it seems to me that sandstorm is trying to use a community/enterprise model. This raises a series of concerns, so I was curious to understand what's your position on this model and how you see it evolve in the future
<Guest43253>
anybody?
<isd>
Guest43253: re: community/enterprise model, what specifically are your concerns? It's notable that unlike many of those, sandstorm for work is still 100% FOSS. You can patch out the need for a feature key and get the LDAP thing and other features, and that's fine, but you don't get support and you have to update from source.
<mnutt>
I can't speak for them but most of the enterprise features are generally only useful for larger entities which are able and willing to spend money on that sort of thing
<isd>
Generally I'm squeamish about "enterprise editions", but that's because they've got proprietary add-ons
<isd>
Worth noting: I have no official affiliation with the project, just a random community member.
<isd>
And even with that, they have substantial discounts/sometimes gratis access to sandstorm for work if you're an individual/non-profit/maybe other things
<isd>
I forget the exact list.
<Guest43253>
isd: my concerns more specifically are that companies that engage in this model usually engage in shitty practices to reduce their efforts on the FOSS/community version and try to lock users into their proprietary version. I've seen many companies do this, making their FOSS version so miserable to the point of being useless, like not working with SSL. There's then the fact anybody of you here contributing to the community version
<Guest43253>
and your free time to a company that is going to sell your free work as proprietary and for profit, treating their community as slaves. By I wan't consider this in this discussion
<Guest43253>
* won't
rafaelmartins has quit [Ping timeout: 245 seconds]
rafaelmartins has joined #sandstorm
ftoad is now known as froggytoad
<_habnabit>
aw, where's dwrensha
<_habnabit>
probably on vacation
froggytoad has left #sandstorm [#sandstorm]
<maurer>
_habnabit: I may be able to answer some questions about the rust canpproto if that's what you're curious about
<_habnabit>
not questions. i just saw some things in the code that could be cleaned up
<maurer>
If you're talking about the rampant use of raw pointers, it turns out to be pretty deeply involved. If it's something else, he might appreciate a PR?
<_habnabit>
nope. just std::mem::replace(&mut x, None) is what Option::take already does
<_habnabit>
so, x.take()
Guest43253 has quit [Quit: Page closed]
<maurer>
There's a difference in destructor behavior I think?
<maurer>
I could be wrong
<maurer>
I also don't know what section of code you're looking at
demonimin has quit [Remote host closed the connection]
demonimin has joined #sandstorm
fonfon has quit [Ping timeout: 248 seconds]
<_habnabit>
hmm. capnp-rpc-rust seems o want to do >1 send/receive cycle even for the basic calculator example
<_habnabit>
this code is a bit twisty. trying to figure out why it needs >1 round trip
<_habnabit>
or, is there a more in-depth specification of the rpc protocol?
<_habnabit>
rpc.capnp has a lot in it, but i didn't know if that's going to document the full flow. really i'd like to see an example client/server flow..
<kentonv>
rpc.capnp is the canonical reference documentation for the protocol. I'm not sure if there are good examples, unfortunately.
<_habnabit>
darn okay
<_habnabit>
i guess i can sniff the stream over a socket and capnp decode
<kentonv>
can you describe what you're seeing?
<kentonv>
like, how are you observing that there are multiple round trips?
<_habnabit>
poorly, i'm sure, but: i made a trivial implementation of an rpc network that has a fixed buffer it uses for incoming reads and a growable one used for outgoing writes, and by hand captured the calculator client's request (with nothing in the read buffer), then put that whole buffer in the server's read buffer and captured its write buffer, and then did it back with the server's response as the
<_habnabit>
client's read buffer, and the client didn't resolve the eval/get_value pipelined promise
<kentonv>
are you sure you captured everything the client wanted to send, and not just the first message? Normally multiple messages will be sent at startup, before waiting for any replies.
<_habnabit>
i saw three distinct messages and concatenated them all
<kentonv>
that sounds about right. Similarly there may be multiple messages coming back from the server.
<_habnabit>
yeah, same there
<_habnabit>
actually.
<_habnabit>
maybe this is a rust-specific question, but if i put all of those messages in one buffer and do capnp::serialize_packed::read_message on it, will i get only the first message?