08:22
<rniwa>
annevk: yt?
08:23
<annevk>
rniwa: yeah
08:23
<rniwa>
annevk: hello
08:23
<annevk>
morning
08:23
<rniwa>
annevk: so my colleague is interested in finalizing ES6 module semantics in HTML
08:24
<rniwa>
annevk: which W3C WG would be appropriate for that?
08:24
<rniwa>
(basically, I'm trying to recruit more people into standards work ;) )
08:24
<Ms2ger>
WHATWG
08:25
<rniwa>
Ms2ger: does that mean it'll be HTML WG in W3C?
08:25
<Ms2ger>
Ding dong, the HTML WG is dead
08:25
<rniwa>
(i know the irony of asking this question on #whatwg)
08:25
<rniwa>
Ms2ger: I'm trying to figure out which meeting he can attend at TPAC if any
08:26
<annevk>
rniwa: W3C is not involved
08:26
<rniwa>
annevk: oh
08:26
<annevk>
rniwa: https://github.com/whatwg/loader is where the work happens
08:26
<rniwa>
annevk: that seems really bad from IP perspective...
08:26
<annevk>
rniwa: I'm not a lawyer
08:26
<rniwa>
annevk: I understand
08:27
<rniwa>
annevk: alright, let me bring that up somewhere sane so that we can get patent protection.
08:27
rniwa
is always paranoid
08:27
<JonathanC>
where can I promote my proposed working group and find people wanting to help implement the specification? and make my coffee and lunch?
08:28
<rniwa>
JonathanC: you can do that at TPAC!
08:28
<rniwa>
JonathanC: join us on hallway conversasions
08:29
<JonathanC>
thanks
08:30
<rniwa>
annevk: btw, is anyone at Mozilla implementing that spec?
08:30
<rniwa>
annevk: at least module part?
08:30
<annevk>
rniwa: well, it isn't really done yet
08:31
<annevk>
rniwa: so we're mostly blocked on design
08:31
<rniwa>
annevk: oh I see
08:31
<rniwa>
annevk: http://trac.webkit.org/changeset/190272
08:31
<rniwa>
annevk: we're pretty much done introducing all the hooks there
08:31
<rniwa>
and we've been waiting for the spec to stabilize but it seems like we need to figure out all the dtails
08:32
<annevk>
I think everyone is at that point now
08:32
<annevk>
well, seems like it, but nobody has taken the time to write up the details
08:33
<rniwa>
okay :(
08:33
<rniwa>
annevk: will you be interested in talking about it at TPAC?
08:33
<rniwa>
unfortunately, I won't know enough about details myself but I might be able to convince someone to along with us ;)
08:35
<annevk>
rniwa: sure, that seems worthwhile
08:35
<rniwa>
annevk: great!
08:36
rniwa
is really excited about modules
08:36
<rniwa>
although I'm also very scared of its perf impact
08:51
<JonathanC>
rniwa: are you saying the event? or is there a channel I can also join
08:51
<rniwa>
JonathanC: http://www.w3.org/2015/10/TPAC/
08:52
<JonathanC>
I dont meet requirments :(
08:52
<rniwa>
oh oops :(
08:53
<JonathanC>
have to work on that first then.
08:54
<JonathanC>
or silently check in some new code into the browser source
08:55
<annevk>
JonathanC: which specification are you talking about?
08:56
<JonathanC>
Just the idea: DataSheets https://www.w3.org/community/blog/2015/10/08/proposed-group-datasheets-community-group
09:03
<botie>
calvaris, at 2015-10-12 18:09 UTC, Domenic said: Hey, any thoughts on the licensing issues for https://github.com/whatwg/streams/pull/397 ?
14:35
<gsnedders>
SimonSapin_: any chance of getting access to Template-Python on PyPi to fix https://github.com/gsnedders/Template-Python/issues/2?
14:36
<SimonSapin_>
gsnedders: same username?
14:36
<gsnedders>
SimonSapin_: yeah
14:36
<SimonSapin_>
done :)
14:39
<gsnedders>
SimonSapin_: takk
14:47
<gsnedders>
SimonSapin_: and pushed a 0.1post1, with a fixed MANIFEST
14:47
<gsnedders>
SimonSapin_: if you care at all
14:48
<SimonSapin_>
good to know that you’re improving this, but yeah I only care as far as building the css2 test suite
14:48
<SimonSapin_>
which I think Ms2ger automated to happen on Travis-CI
14:49
<gsnedders>
SimonSapin_: that's all I really care, too
14:49
<gsnedders>
SimonSapin_: but the broken MANIFEST meant that it wouldn't work for building the CSS testsuites
14:50
<JakeA>
Domenic: probably stupid question, could the readable stream controller be piped to?
14:53
<SimonSapin_>
ok, thanks for fixing it
14:54
<Ms2ger>
gsnedders, the bogus names are what's being tested :)
14:55
<gsnedders>
Ms2ger: ohhh
14:55
<Ms2ger>
gsnedders, I sure hope nobody would come up with those accidentally :)
14:55
<gsnedders>
Ms2ger: I really didn't investigate closely :)
15:10
<Domenic>
JakeA: no, the RSC is just a holder for a few methods, think of it like just an object literal.
15:10
<JakeA>
gothca, cheera
15:10
<JakeA>
and cheers
15:55
<wanderview>
MikeSmith: do you know about the w3c validator?
15:58
<wanderview>
MikeSmith: does the feed validator have a different tls deployment? it seems to fail on tls for my blog feed here: https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fblog.wanderview.com%2Fatom-mozilla.xml
16:00
<gsnedders>
wanderview: AFAIK they're entirely different, just with a vaguely common front-end
16:00
<wanderview>
hmm, but I get success if I enter the URL on validator.w3.org/ : https://validator.w3.org/check?uri=https%3A%2F%2Fblog.wanderview.com%2Fatom-mozilla.xml&charset=%28detect+automatically%29&doctype=Inline&group=0
16:01
<wanderview>
hmm
16:01
<wanderview>
gsnedders: thanks
16:03
<gsnedders>
wanderview: notably, the feed validator uses http://feedvalidator.org, presumably with some Python HTTP library and whatever TLS setup that uses (likely OpenSSL in some configuration or other)
16:12
<MikeSmith>
wanderview: what gsnedders said
16:12
<wanderview>
ok, thanks
16:12
<MikeSmith>
I know the feed validator at least has problems wish SNI
16:13
<MikeSmith>
I believe that's because python 2.7 doesn't do SNI
16:14
<MikeSmith>
it may also have other TLS problems beyond that
16:15
<MikeSmith>
last I knew, Sam Ruby was the one maintaining the feed-validator code
16:18
<jgraham>
2.7.9 supports SNI
18:30
<JakeA>
wanderview: is there a comment in the streams centithread that explains why a revealing constructor (even if it's called straight away) is bad, and your transform stream / pipe solution is good?
18:31
<wanderview>
JakeA: you mean in issue 30?
18:31
<JakeA>
wanderview: or #59, yeah
18:32
<JakeA>
wanderview: https://github.com/yutakahirano/fetch-with-streams/issues/59#issuecomment-147773920 - I get that one of the bodyWriters here will be used, and 2 of them won't, but I don't get why that's bad, or why creating 3 pipes would work around the badness
18:33
<wanderview>
JakeA: you don't create 3 pipes... just one pipe... and you can then later pick which ReadableStream to write into the pipe
18:36
<wanderview>
JakeA: not sure there is a good summary comment in issue 30, but I think this one somes up a lot of my opinions: https://github.com/yutakahirano/fetch-with-streams/issues/30#issuecomment-93039367
18:37
<wanderview>
JakeA: also note, a lot of the issues in comment 30 were more about Request than Response...
18:46
<JakeA>
cheers!
18:48
<JakeA>
wanderview: so why can't new Response(writableStream => cacheResponse.pipeTo(writableStream)) be optimised in the same way (done off thread), or is it just API preference?
18:52
<frewsxcv>
https://html.spec.whatwg.org/multipage/#ask-for-a-reset
18:52
<wanderview>
JakeA: well, I was thinking more for Request... with a pipe you can move the pipe off thread immediate on fetch(request)... with the writer revealer function I have to go back to javascript once I have the tcp connection established and the outgoing upload stream ready to write to... this is an extra round trip to js
18:52
<frewsxcv>
"If the multiple attribute is present..."
18:52
<frewsxcv>
is that paragraph part of the 'ask for a reset' section?
18:53
<wanderview>
JakeA: I would be happy to allow the revealer function if it just implied "automatically create a pipe and caller revealer function with writer side of pipe"
18:53
<wanderview>
I think its unnecessary API contortions, though
18:54
<wanderview>
JakeA: Request and Response are inherently time-disconnected from the event that consumes them... so I think a buffered pipe is the correct representation for their body streams
18:55
<wanderview>
because time-disconnected effectively requires buffering
18:56
<JakeA>
thanks! I think I get it now
18:57
<Domenic>
The time-disconnected => writable stream revealer does not work argument makes a lot of sense to me
18:57
<Domenic>
That led me to the idea of putting the writable stream somewhere else
18:57
<Domenic>
But the pipe version also looks nice and simple
18:57
<Domenic>
So if tyoshino and yhirano_ are OK with it then it sounds good to me
18:58
<JakeA>
what's the difference between this pipe thing and a null transform stream?
18:58
<Domenic>
JakeA: pipe is what wanderview likes to call identify transform stream
18:59
<Domenic>
POSIX has a similar concept called pipe
18:59
<wanderview>
pipe is shorter
18:59
<JakeA>
hah, gotcha
19:02
<JakeA>
not that it matters, but wanderview's pipe idea sounds great to me
19:03
<wanderview>
I guess we also call it a pipe in gecko
19:03
<JakeA>
Domenic: wanderview: is it worth having a Pipe() constructor, or would it just be TransformStream with no transform specified?
19:04
<Domenic>
JakeA: I am not sure yet but I would prefer the latter. I think in theory that should work given that the reader and writer and pipeThrough/pipeTo design is all locked down to allow optimizations...
19:04
<Domenic>
this means i'm going to have to get my stuff together and finish writable streams/transform streams, eek.
19:05
<Domenic>
i was hoping that getting author-constructed readable streams in chrome would be enough
19:05
<JakeA>
Domenic: wanderview: just so you know I've been telling everyone that streams will be the major web platform addition of 2016 so you better not fuck this up
19:05
<JakeA>
:D
19:05
<Domenic>
(almost done with that patch)
19:05
<Domenic>
haha
19:05
<Domenic>
2016 we can manage
19:06
<wanderview>
JakeA: well, at the right things are going... no promises
19:06
<JakeA>
Well, even with readable streams I can prototype the perf benefits from within a service worker
19:06
<Domenic>
that's true
19:07
<JakeA>
If it beats the current client render strategy of https://wiki-offline.jakearchibald.com/ *before* optimisation, that's pretty big news
19:08
<Domenic>
It seems like there would be some cost in evangelizing one pattern only to later evangelize the better one though
19:09
<Domenic>
I guess that's life on the bleeding edge...
19:10
<JakeA>
Well… it depends where you're coming from. If you're starting with a JS client driven SPA, the shell approach works with little modification
19:10
<JakeA>
If you're a server driven site, the streaming approach is less invasive than having to create a client-driven thing
19:11
<JakeA>
I wouldn't change https://jakearchibald.github.io/svgomg/ for instance.
19:31
smaug____
assumes wpt doesn't have too many session history tests
20:36
<gsnedders>
smaug____: mostly the ones jgraham wrote while at Opera that finally got merged. from memory, the number isn't massive, but they're quite evil.
20:38
<smaug____>
I'm in process of hacking push/replaceState handling when called during page load
20:43
<jgraham>
smaug____: I'm not sure I wrote tests for that specific case
20:43
<jgraham>
But we will see
20:43
<jgraham>
Also if I didn't you should :)
20:43
<jgraham>
Also if I did you should
20:46
<gsnedders>
jgraham: I'm pretty sure you did.
20:48
<jgraham>
Maybe! But smaug still should.
20:49
<smaug____>
iik
20:49
<smaug____>
but yes, I should
20:50
<smaug____>
session history is after all this nice piece of web platform which isn't specified nor implemented properly anywhere
20:50
<jgraham>
And whiuch servo still has to implement
20:50
<jgraham>
So there's a very clear payoff there
20:50
<jgraham>
Also lag
20:50
<jgraham>
Can't see anything I'm typing
20:51
<gsnedders>
jgraham: can you remember what happened with all the Core 3 feedback, or did it just all fall into the category of "we need to rewrite all of this, because who knows what we need, halp"?
20:53
<jgraham>
I filed some bug reports
20:53
<jgraham>
I don't know what happened to them