| 08:53 | <MikeSmith> | anybody used letsencrypt yet for a cert for one of your domains? |
| 08:55 | <ondras> | yes |
| 08:55 | <ondras> | I did |
| 08:56 | <ondras> | about a week ago |
| 09:09 | <philipj> | MikeSmith: me too, and davve |
| 09:19 | <MikeSmith> | ondras, philipj: was the setup as easy as you'd expected? do you know roughly how long it took you? |
| 09:23 | <philipj> | MikeSmith: it was more manual than I expected, and I probably spend 4-8 hours on it in total, two evenings I think |
| 09:23 | <philipj> | well, getting the certs was pretty quick, but tweaking everything to make https://www.ssllabs.com/ssltest/ happy took more time |
| 09:24 | <ondras> | agreed |
| 09:24 | <MikeSmith> | ok |
| 09:24 | <MikeSmith> | that's kind of what I figured |
| 09:24 | <ondras> | getting the cert was easy, using the "certonly" feature |
| 09:24 | <MikeSmith> | ok |
| 09:24 | <ondras> | it worked OOTB using the git version |
| 09:25 | <MikeSmith> | cool |
| 09:25 | <philipj> | ondras: were you running an HTTP server on that host at the time? |
| 09:25 | <ondras> | but getting an "A" rank (just for teh lulz, probably) meant updating to apache 2.4 |
| 09:25 | <ondras> | on my old debian box |
| 09:25 | <ondras> | philipj: yes, precisely |
| 09:25 | <ondras> | and updating apache 2.2 -> 2.4 was a major pita |
| 09:25 | <philipj> | I was, and thus I coulnd't use the automatic stuff, had to had some files to make my exsiting server serve the files |
| 09:25 | <ondras> | due to poor and old vhost config on that machine |
| 09:25 | <philipj> | had to *add* some files, and change the Content-Type too |
| 09:25 | <ondras> | well the "certonly" with "--webroot" worked automatically for me |
| 09:26 | <ondras> | it placed some files to webroot, used them and removed afterwards |
| 09:26 | <ondras> | I think that one empy .someletsencryptstuff dir remained there |
| 09:26 | <ondras> | I deleted that manually |
| 09:26 | <ondras> | *empty |
| 09:27 | <philipj> | oh, I didn't know about --webroot |
| 09:27 | <ondras> | MikeSmith: I also had to install some packages to satisfy dependencies, as letsencrypt was not available as a .deb package for my distro |
| 09:27 | <ondras> | MikeSmith: but just getting this thing set up and getting the cert was about half an hour of work |
| 09:27 | <ondras> | pretty easy even with my lame admin skills |
| 09:29 | <MikeSmith> | ondras: good to know. And I'm running Debian testing, so I reckon I shouldn't have a problem with getting the packages |
| 09:31 | <MikeSmith> | for the first domain I want to set up I also already have my nginx tweaks in place with my existing cert at a full A+ https://www.ssllabs.com/ssltest/analyze.html?d=sideshowbarker.net |
| 09:31 | <MikeSmith> | so I'm hoping I won't need to (re)make those changes |
| 09:32 | <MikeSmith> | current cert expires in February so I reckon switching over before then would be good |
| 09:32 | <MikeSmith> | nice holiday project |
| 09:37 | <ondras> | cool |
| 09:37 | <ondras> | shall be straightforward in your case |
| 09:37 | <ondras> | good luck :) |
| 09:41 | <MikeSmith> | cheers |
| 09:41 | <philipj> | ondras: did have trouble with https://github.com/letsencrypt/letsencrypt/issues/1668 ? |
| 09:42 | <ondras> | philipj: no. I used "--webroot -d domain.name -w /path/to/webroot" |
| 09:43 | <ondras> | not sure if the bug applies in this setup |
| 10:02 | <philipj> | ondras: thanks, that worked, now renewing is just a one-liner :) |
| 10:02 | <ondras> | exactly :) |
| 10:50 | <annevk> | I guess for whatwg.org we'll just wait for DreamHost to roll out Let's Encrypt... |
| 10:50 | <annevk> | Unless that doesn't happen by the summer, in which case we might have to do something one way or another |
| 13:41 | <annevk> | Domenic: JakeA: what do you think about the suggestion in https://github.com/whatwg/fetch/issues/20#issuecomment-164421065? |
| 13:57 | <JakeA> | annevk: why does that need to be an api, given it can be implemented on top of abort() really easily? |
| 13:58 | <annevk> | JakeA: I guess folks don't want to wait for abort() |
| 13:58 | <annevk> | JakeA: but yeah, you're right |
| 14:00 | <JakeA> | annevk: maybe we need to look for an abort solution that doesn't have as many external dependencies as cancellable promises :/ |
| 14:01 | <JakeA> | Domenic: did I see you post that there'd been discussions on cancellable promises at tc39? |
| 14:02 | <annevk> | JakeA: that is an alternative, though none look attractive enough |
| 14:02 | <annevk> | JakeA: basically the API would become worse than XHR, afaict |
| 14:09 | <Domenic> | JakeA: kind of, basically still waiting on me though. |
| 14:10 | <Domenic> | annevk: I definitely don't like providing a halfway abort method |
| 14:10 | <Domenic> | annevk: I think waiting is still the right move here tbh. XHR isn't going anywhere for now. |
| 14:11 | <Domenic> | annevk: the only feasible thing I can think of is if we say that cancelation/abortion is different from timeout, and timeout is somehow actually an error condition. In which case adding a sugary { timeout: ... } option seems somewhat OK. |
| 14:13 | <JakeA> | Domenic: I still think it's better composed in that case |
| 14:15 | <JakeA> | A timeout being a time-based reaction, where aborting the request will be one part, but rejecting could be another |
| 14:18 | <annevk> | Domenic: XMLHttpRequest is not exposed in service workers, but I guess the latter are still somewhat experimental |
| 14:22 | <Domenic> | JakeA: I don't think I understand what you're saying |
| 14:23 | <Domenic> | Oh hmm I think I do now |
| 14:23 | <JakeA> | Domenic: I could create a promise that aborts a fetch then rejects |
| 14:23 | <Domenic> | yeah, makes sense |
| 14:23 | <Domenic> | But we could say that { timeout } is sugar for that |
| 14:24 | <Domenic> | instead of sugar for just aborting the fetch |
| 14:55 | <wanderview> | JakeA: in regards to your comment here, I personally don't like streams for progress notifications https://github.com/whatwg/fetch/issues/20#issuecomment-164457161 |
| 14:56 | <wanderview> | JakeA: its problematic to get the same "progress based on when bytes are written-to/read-from OS kernel" that we have today with streams that might be piped together through many layers, etc |
| 14:57 | <wanderview> | thought I would mention it here, since that issue is not really about progress |
| 14:58 | <JakeA> | Domenic: why is sugar for timeout ok, but sugar for failing on a non-success code not ok? |
| 14:59 | <JakeA> | wanderview: hmm, does that apply to both uploads and downloads? |
| 15:00 | <wanderview> | JakeA: definitely applies to uploads... I'm unsure about the requirements for downloads |
| 15:00 | <wanderview> | JakeA: requiring someone to hook the stream seems very heavyweight from an API perspective as well |
| 15:01 | <wanderview> | JakeA: I'd rather just have progress events |
| 15:01 | <annevk> | ProgressPromise? |
| 15:02 | <annevk> | wanderview: is this something that can wait though? |
| 15:02 | <annevk> | wanderview: seems like doing some iterations with streams first would be good before we go higher-level again |
| 15:02 | <wanderview> | annevk: I only mention it because I see people saying "streams is the primitive for progress everyone should plan on using" |
| 15:03 | <wanderview> | annevk: not if it means we have to contort the streams implementation to accomodate these weird "progress-at-the-kernel" requirements |
| 15:03 | <annevk> | wanderview: what does the browser use internally for progress events? |
| 15:03 | <wanderview> | if we can relax those requirements, then fine by me |
| 15:03 | <wanderview> | annevk: for uploads it fires events based on when things write() is called on the socket |
| 15:04 | <wanderview> | annevk: not based on when it reads the data out of the upload stream |
| 15:05 | <annevk> | I see |
| 15:06 | <annevk> | wanderview: you don't think placing progress observers on streams makes sense at all? |
| 15:07 | <Domenic> | JakeA: it's not really OK. |
| 15:07 | <wanderview> | annevk: sure it does, but I don't think trying to make a streams progress reflect downstream operations (like writing to the kernel) makes sense... |
| 15:08 | <wanderview> | annevk: so if people are ok with it not really being at the external interface boundary, I'm fine with it |
| 15:11 | <annevk> | wanderview: I'm not sure what that means |
| 15:11 | <annevk> | wanderview: what JakeA said in that issue makes sense to me and has been our idea about "progress" for a while |
| 15:12 | <annevk> | wanderview: if that is wrong, file an issue against streams? Or maybe against fetch? Though it seems like the streams folks would have to be convinced we need something else |
| 15:14 | <wanderview> | annevk: ok... I haven't seen the issue or PR to add this stuff... so its a bit abstract still... I am just thinking back to the debates about WritableStream for Request.body with the goal of trying to get progress at the os kernel layer... I think we backed away from that... I want to make sure we don't end up there again |
| 15:14 | hsivonen | discovers that the ISO-2022-JP decoder in the Encoding Standard can unread two bytes after reading one byte |
| 15:15 | <hsivonen> | :-( |
| 15:16 | <annevk> | hsivonen: I think you need a buffer of three or so |
| 15:16 | <wanderview> | annevk: I guess another way to state my view... I'm fine with a progress monitor on a stream as long as its monitoring the state of that stream instance and not something else in the system |
| 15:16 | <hsivonen> | annevk: why three? |
| 15:17 | <hsivonen> | I don't want to implement any actual prepending. Unreading the byte that was just read is fine, though. Just moves the pointer backwards in a way that's never out of bounds. |
| 15:18 | hsivonen | tries to work out what'll happen next when the two prepended bytes are processed |
| 15:19 | <annevk> | hsivonen: oh, maybe two is sufficient with the prepend rewrite, I was just going from memory and what Joshua told me at some point |
| 15:21 | <annevk> | wanderview: that makes sense |
| 15:21 | <hsivonen> | looks like I will need to work out what the possible combinations for the fields of the ISO-2022-JP decoder are at the end of the escape state :-( |
| 15:21 | <annevk> | wanderview: perhaps it's worth raising an issue on fetch-with-streams then to point out XMLHttpRequest progress events cannot be done on top of streams? |
| 15:32 | <annevk> | Domenic: thank you btw for rewriting the way workers work |
| 15:32 | <annevk> | Domenic: it bugged me too, but I thought rewriting it would require changing the way MessageChannel works |
| 15:34 | <annevk> | Domenic: seems you carefully navigated around that |
| 15:35 | <Domenic> | Yeah, that was... fun :) |
| 15:43 | <annevk> | Domenic: should we have some compat label for HTML issues? To indicate interop issues and make it easier to track them? |
| 15:44 | <Domenic> | annevk: what were you thinking? |
| 15:45 | <JakeA> | annevk: wanderview: streams for reading downloads makes sense to me. When I report 50% done I expect to have 50% of the resource in my possession (ignoring lies in content-length). I agree that it might not fit for uploads. |
| 15:46 | <JakeA> | Since its possible for my stream to be 100% consumed but none of it sent to the server. Especially as fetch does its own buffering for redirects |
| 15:46 | <wanderview> | JakeA: yea... download is less problematic than upload... I guess because download is about "read status", while upload is really about "write status" |
| 15:46 | <annevk> | Domenic: a label called "compat" e.g., for https://github.com/whatwg/html/issues/387 which I guess is an addition/proposal, but not really in the same sense |
| 15:47 | <Domenic> | Yeah I still think sent to the kernel or TCP ACKed would be ideal, but wanderview doesn't want to implement that :( |
| 15:47 | <Domenic> | annevk: seems reasonable, yeah |
| 15:47 | <wanderview> | Domenic: I don't mind implementing it (we do it today)... I just don't want a stream created before actually opening the socket to report that status |
| 15:48 | <Domenic> | wanderview: hmm I am confused, when was anyone proposing that? |
| 15:48 | <wanderview> | Domenic: back when there was the suggestion Request should provide a WritableStream |
| 15:48 | <wanderview> | not recently |
| 15:49 | <Domenic> | I don't understand. The writable stream proposal was never saying that the write() method on the writable stream should report that status before the socket is opened. |
| 15:51 | <wanderview> | Domenic: I'm saying the Request object is time disconnected from the socket write... so is not a good place to report written-to-os-kernel status... but I don't really want to replay the whole debate again |
| 15:52 | <Domenic> | wanderview: right, OK. I was thinking of the proposal where we have a separate API for establishing an upload writable stream, not accounting for Request per se. |
| 15:52 | <Domenic> | But yeah I remember the time-disconnectedness of Request being a problem. |
| 15:52 | <wanderview> | I guess I just want to make sure we know we need something other than stream progress monitor to achieve XHR upload progress events |
| 15:54 | <Domenic> | yeah |
| 15:54 | <Domenic> | I think my current mental model is that there is a separate establishUploadWritableStream() API |
| 15:54 | <Domenic> | and fetch(request) does const ws = establishUploadWritableStream(); request.body.pipeTo(ws) |
| 15:55 | <Domenic> | just a mental model though |
| 16:00 | <wanderview> | Domenic: implementation will likely be very different from that... javascript runs in the child process while writting the upload stream to the kernel will take place in the parent process |
| 16:03 | <annevk> | Domenic: reportedly bz (on vacation now) has a promise implementation of toBlob somewhere in a Mozilla bug |
| 16:03 | <annevk> | Domenic: just waiting for a decision on a new name and such |
| 16:04 | <Domenic> | annevk: we should decide on a name and let blink-dev know then... |
| 16:05 | <annevk> | I'm happy with encode/convert, but would be good to double check with bz in January |
| 16:05 | <Domenic> | HTML's use of ES ArrayBuffer vs. IDL ArrayBuffer is pretty confused still hmm what should I do |
| 16:06 | <annevk> | Domenic: structured clone biting you? |
| 16:06 | <Domenic> | I would use IDL everywhere but the spec likes to talk about "creating ArrayBuffers" which IDL doesn't really deal with |
| 16:06 | <annevk> | Domenic: oh <canvas> |
| 16:07 | <annevk> | Domenic: in theory IDL should deal with that to some extent, to make sure the object setup is correct |
| 16:07 | <annevk> | Domenic: e.g., when we say "a new promise" or "a new XMLHttpRequest object", it has all the same problems |
| 16:07 | <Domenic> | Yeah |
| 16:07 | <Domenic> | I guess I'll switch to IDL everywhere? |
| 16:07 | <annevk> | Domenic: yeah, structured cloning itself should probably move to IDL or be rewritten to some extent |
| 16:08 | <annevk> | Domenic: but just creating objects should be fine and IDL needs some language around what "new" means or "create" |
| 16:08 | <annevk> | Domenic: similar to how it has language around "throw" |
| 16:08 | <annevk> | Domenic: ideally longer term it also defines loops and such |
| 16:26 | <annevk> | Domenic: sad that it fall upon you to define globalThis in JavaScript, but glad you did |
| 16:26 | <Domenic> | yeah glad to finally knock that out |
| 16:26 | <annevk> | Domenic: so that was the other thing I wanted to ask about, should we use "JavaScript" or "ECMAScript" throughout? |
| 16:27 | <Domenic> | annevk: the current spec has a note about that somewhere |
| 16:27 | <annevk> | Domenic: it seems IDL uses ECMAScript, most WHATWG specs, including the one named javascript, use JavaScript |
| 16:28 | <annevk> | I think even (some of) TC39 wants to use JavaScript, but Brendan mentioned some issues with Oracle iirc |
| 16:28 | <Domenic> | "The term "JavaScript" is used to refer to ECMA262, rather than the official term ECMAScript, since the term JavaScript is more widely known." |
| 16:28 | gsnedders | waits for Oracle sue |
| 16:28 | <Domenic> | I think using JS is pretty good |
| 16:28 | <gsnedders> | annevk: there are issues with Oracle because they own the JavaScript trademark |
| 16:28 | <annevk> | Okay, I guess we should just stick to that then |
| 16:28 | <Domenic> | Hmm I won't bother updating this "lives in a window"/"lives in a worker" thing. It is not as easy in HTML as it is in XHR. We should just kill those sections ASAP. |
| 16:30 | <Domenic> | BTW I am having ES take over the stack of scripts basically |
| 16:31 | <Domenic> | It will also work with modules |
| 16:31 | <Domenic> | (This is not in the current PR, it's upcoming) |
| 16:31 | <Domenic> | https://github.com/tc39/ecma262/pull/242 |
| 16:32 | <annevk> | Domenic: including script settings? |
| 16:32 | <annevk> | Domenic: or will those remain HTML things? |
| 16:33 | <Domenic> | I think script settings will stay for noe |
| 16:34 | <Domenic> | But each ES script/module will have a [[HostDefined]] slot containing the script settings object. And so ES can track the stack of them. |
| 16:38 | <annevk> | https://en.wikipedia.org/wiki/JavaScript#Trademark suggests Mozilla has a license for use of the JavaScript trademark, but the link does not really verify that claim |
| 16:47 | <annevk> | Domenic: if you instantiate your own Realm don't you get a different kind of global associated with it? But I guess things can be refactored once that actually happens |
| 16:47 | <Domenic> | annevk: hmm perhaps true... but yeah. |
| 16:55 | <annevk> | Domenic: I made some progress last week btw on figuring out what the setup for Location needs to become and also Window/WindowProxy |
| 16:55 | <annevk> | Domenic: it seems like WindowProxy will need to handle all the security checks currently on Window too |
| 16:56 | <Domenic> | annevk: good to hear yeah... still not sure how to best handle the IDL vs. not-IDL thing |
| 16:56 | <annevk> | Domenic: Location becomes an IDL thing, but IDL will also support redefining internal methods for IDL things |
| 16:56 | <Domenic> | Hmm |
| 16:57 | <Domenic> | One path I thought might work is to define Window + Location in IDL completely but then define WindowProxy + LocationProxy in ES terms |
| 16:57 | <Domenic> | (or, I guess, Window + BackingLocation and WindowProxy + Location) |
| 16:57 | <Domenic> | But by now you are much more familiar with the problem space than I. |
| 16:58 | <wanderview> | annevk: I guess this is related? https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/bpbq0Rcpauk |
| 16:58 | <wanderview> | maybe we don't need that level of granularity any more? |
| 17:13 | <annevk> | wanderview: that's not related |
| 17:13 | <annevk> | wanderview: that's some legacy stuff, older names for "loaded" and "total" https://xhr.spec.whatwg.org/#interface-progressevent |
| 18:31 | <JakeA> | wanderview: been bouncing the idea of transactional cache stuff in my head. Starting to settle on something like cache.transactionUntil(promise) - meaning this instance of cache holds a write-lock until the promise settles |
| 18:31 | <JakeA> | (or the instance is GC'd, which could be a sticking point) |
| 18:32 | <paxcoder> | annevk: Hello. Months have passed. It's time for me to ask about UndoManager again. What's up with it, what is its problem? Is it missing a consistency model, is that is? Or is there a simpler reason why it's stuck on the 2012 Niwa draft? |
| 18:33 | <JakeA> | wanderview: I'm moving away from batching, as it doesn't allow you to read from a cache, then do writes based on what you read |
| 18:33 | <annevk> | paxcoder: heh, I'm not sure |
| 18:34 | <annevk> | paxcoder: Gecko reportedly has some implementation of which the state is unclear to me; rniwa left Google and joined Apple and at the same time realigned interests I think |
| 18:34 | <annevk> | paxcoder: so, there's nobody that's working on it, and nobody is really interested in pursuing it as far as I can tell |
| 18:35 | <paxcoder> | That's weird. Esp. with Github's Atom editor and Microsoft's fork. |
| 18:38 | <annevk> | Well, what does have some traction is a different more low-level approach to editing |
| 18:39 | <paxcoder> | What do you mean? |
| 18:39 | <annevk> | So perhaps if that is done UndoManager can be a thing that is implemented by the application more easily |
| 18:39 | <annevk> | I haven't really followed what is going on since it's not clear to me it's going well, but https://w3c.github.io/editing/ |
| 18:43 | <Domenic> | JakeA: you should talk to jsbell; he has ideas around transactions/locking/etc. in general. |
| 18:44 | <paxcoder> | annevk: If I'm silent I'm looking into things, doesn't mean I don't appreciate. FYI |
| 18:46 | <paxcoder> | annevk: BTW. While I'm reading this, I ran into your voice on... what was it.. The Web Platform Podcast perhaps? Idk. Anyway still refreshing my feeds hoping to scoop up a blog post of yours some time. |
| 18:47 | <annevk> | paxcoder: ah yes, I have an idea for a blog post now, so maybe it'll happen :-) |
| 18:47 | <annevk> | paxcoder: and I did appear on such a podcast once, so perhaps |
| 18:48 | <JakeA> | Domenic: yeah, I know IDB is going with the waitUntil model, but good point about locking. I'd like to get away with write-locking only, but this is where I have less experience. |
| 18:48 | <annevk> | paxcoder: and yeah, I think having UndoManager handled by the browser could definitely help out a bunch of folks, but I think in the end it hasn't been fully tackled since it was too hard and editing in the browser still largely sucks |
| 18:49 | <annevk> | paxcoder: perhaps you can reach out to rniwa on Twitter or IRC somewhere and get a more complete story |
| 18:50 | <paxcoder> | annevk: The looks of these input events remind me of iOS, but iOS has rich string thingies, and the web does not, so I don't see how that helps with syntax highlighting or WYSIWG editors. What will the blog post be about if I may inquire? |
| 18:55 | <paxcoder> | annevk: does rniwa come here or did you mean some other channel? |
| 18:58 | <paxcoder> | Question for everybody: What do you use instead of caniuse.com? |
| 18:59 | paxcoder | begins to suspect execCommand may have something to do with the missing richstring feature |
| 19:04 | <paxcoder> | interesting |
| 20:02 | <wanderview> | JakeA: I'd like to know the real world use case driving transactions for Cache |
| 20:04 | <wanderview> | JakeA: or another way to ask the question... if some needs the complexity of transactional behavior, can they just use IDB? |
| 20:14 | <wanderview> | JakeA: also, I think we already have a transaction mechanism in SW... the install and activate events |
| 20:14 | <wanderview> | maybe thats over stating it, but they fill a similar role |