<Draft_FR>
Why freenode and not rocketchat I mean ?
<isd>
I think human-memorable grain links aren't a thing yet, except for static publishing. Though it's an often requested thing
<TimMc>
Because the chatrooms I want to be in are in IRC, not rocketchat. (Also, IRC clients are lightweight and can be hosted on my raspberry pi that I ssh into...)
<isd>
re: rocketchat, not having made the decision I couldn't tell you, but I think Freenode has enough weight behind it that it's worth having a presence here.
<isd>
On a personal note, +1 to TimMc's note of having lighter weight clients
<isd>
esp. since I'm in IRC for other stuff too
<TimMc>
Draft_FR: Oh! By "you" you mean sandstorm, not me personally. I'm just a user, I'm not part of the project itself.
<isd>
Though it has occurred to me in the past that having a community rocket-chat grain might be a neat way to demo stuff, as well as reach out to folks that get turned off by the IRC UX, which... could be better.
<TimMc>
True, but it would be a tradeoff. Gain some folks, lose others.
<isd>
Speaking of powerbox integration stuff, I have a tech demo I'm finishing up, then going to post an announcement.
<TimMc>
cool :-)
<Draft_FR>
@TimMc Yeah I meant sandstorm ;)
<isd>
Short version: filesystem protocol + demos
<TimMc>
Hey, are always-on grains a thing? I was thinking how it would be neat to write a CSP report-uri receiver endpoint hosted in Sandstorm.
<Draft_FR>
@isd Seems great ! :)
<isd>
TimMc: what do you mean by "always on?"
<TimMc>
Not requiring grain startup if used infrequently.
<isd>
Ah. You could acquire a wakelock. But for the thing you're describing I'd just build it with something that has good startup times.
<TimMc>
I guess what I'm thinking of would be API grains -- always running, stable name, accept a variety of HTTP requests.
<Draft_FR>
@isd if I'm following you we could have bridges between freenode and rocketchat channels ?
<isd>
Draft_FR: might be an interesting project. I don't know how easy it would be/seamless it could be made.
<isd>
TimMc: Is the startup penalty the only reason for wanting to be always-on?
<isd>
The kind of thing you describe is pretty common. Piwik is your classic example.
<Draft_FR>
kiwirc ?
<TimMc>
Yeah, latency on infrequent requests, especially infrequent bursts.
<TimMc>
I usually program in Clojure, which takes some number of seconds to start up.
<TimMc>
I guess a wakelock would work for that if the grain is really supposed to be always-on.
<TimMc>
It could provide its own "sleep" timeout that way -- release the wakelock after an hour to let normal shutdown occur.
<isd>
The JVM on sandstorm is no fun either.
<isd>
Does clojurescript on node start any faster?
<isd>
There's also snappy-start, which is kentonv's notion of how to deal with slow-to-start runtimes.
<isd>
Startup times are one of the things that has kept me away from clojure.
<TimMc>
Yeah, if there's support for process images, that's fine.
<TimMc>
Well, I mostly use Clojure for servers, where it doesn't particularly matter. :-)
<TimMc>
I certainly miss being able to reasonably use it for scripting.
<isd>
Yeah. I think I once had an android hello-world take ~8 seconds to start on some phone, and was like... NOPE! But that was quite a while ago
<TimMc>
Oh man, the android stuff is a whole 'nother thing.
<TimMc>
It might be faster now, but Clojure + Android used to be *awful*, I think because of how a lot of the optimization are with the normal JVM in mind.
<isd>
Yeah, like I said, this is a *very* long time ago
<TimMc>
And... something about how Android really chokes on large numbers of classfiles maybe? Dunno the current state.
<isd>
Last time I messed with android it was using scala, which was relatively fine
<TimMc>
interesting
<TimMc>
I don't know what the cljs node startup times are like, by the way.
<DanC_>
setExec is only on RwFile? sorta orthogonal to write permission. hm. maybe not
<isd>
DanC_: Re: the streams, It's basically a trick to allow streaming a bunch of data without blocking the rest of the RPC connection. You see the same pattern in other places in the API; e.g. ipNetwork, websockets, etc. You generally have push interfaces, not pull
<isd>
Which can get a bit weird from a programmer perspective. I end up using Go's io.Pipe() a lot to invert the control flow.
<isd>
I guess I was treating write as a general modify. The big weirdness is that I decided to omit "ownership" entirely. So it kinda falls out of that?
<DanC_>
"allowing flow control at either end" . hm... I don't see flow control knobs. (reading util.capnp)
<isd>
But I could definitely be convinced otherwise. Per the comment at the top, this is still up for debate.
<isd>
kentonv can probably explain the ByteStream thing better than I can. But, basically, if you just had a read() that returned a big slice of Data, it would block the whole connection until everything was transferred. If the caller broke it up into smaller chunks, you have to worry a lot about latency and round-trips. It's a bit simpler to deal with if you just hand it something and say "write the data into this."
<isd>
It's definitely one of the weirder things to get used to in the sandstorm API.