Engineer on @googlechrome. Involved in CSS and W3C standards. Previously @mozilla, @w3ctag. Mastodon: @dbaron@w3c.social
Rockville, Maryland, USA
Joined March 2008
- Tweets 7,521
- Following 1,244
- Followers 4,296
- Likes 18,519
I don't think it's useful to give advice we know people aren't going to follow. The first step is the work of building enough consensus around restricting all features to secure contexts as a lever to move to TLS. Declaring it without enough momentum behind it doesn't help.
1
3
But session restore loves to restore GitHub comments that I *have* sent. Often showing up right below their submitted form.
Someday I should figure out what's at fault...
3
Nobody would ship a rendering engine with changes that broke lots of websites that their users care about. Having just one engine would make all the sites much more sensitive to small changes, even in newish features.
2
If that were the case, there would be much less freedom to change anything because sites would break in response to minor changes much more than today.
2
Though I think it's not just the cost of building an implementation of the Web, but also the cost of building products that make that implementation relevant. An implementation of the Web can't help users without widely used products built with a similar set of values.
1
1
My one good experience with a transit app was in Switzerland, where IIRC the same app worked on the national train network and also worked on many local buses. And the app actually worked, with integrated route search and purchase, etc.
Ah, makes sense that Handle::spawn needs no error and that's different from Core::run.
I guess I had the wrong docs for Handle since I was confused by looking at:
docs.rs/tokio/0.1/tokio/reac…
when I should have been looking at:
docs.rs/tokio-core/0.1/tokio…
1
Curious if pastebin.mozilla.org/9081121 leads to immediate advice, though. (I'm confused, since the inner type is std::result::Result<(), std::io::Error> so I'd think the outer Error type would be std::io::Error and not ().)
1
Yeah, I was just rereading that; I hadn't realized that Stream::for_each produced a future rather than a stream, but I realized it just before seeing your response.
1
1
What I was trying to do was pass the stream off to the Core or Handle to run (pump?) it to completion. I'd thought I'd done that before, but in hindsight I'd only passed the result of stream.join(future) to one elsewhere in a way that worked.
1
I don't yet have an intuitive sense of rust error checking stages beyond knowing that I won't get borrow checker errors until I've fixed everything else.
1
On the other hand, maybe these inscrutable errors weren't caused by what I thought they were caused by, because now that I've converted everything back to old tokio I get them again.
1