| 07:44 | <annevk> | deltab: FWIW, we are considering an API at some point |
| 07:45 | <annevk> | deltab: if you have anything in particular you'd like to see, please let me or mkwst know |
| 08:57 | <mkwst> | annevk: Do you have a minute to talk about Fetch and credentials and FormData and URLSearchParams? |
| 09:06 | <annevk> | mkwst: sure |
| 09:06 | <mkwst> | annevk: We discussed briefly in person: folks want to be able to submit urlencoded data. The current model (`fetch(..., credential.toFormData())`) results in a multipart submission. That's unfortunate. |
| 09:07 | <mkwst> | annevk: One suggestion was to add a `toURLSearchParam` analog to `toFormData`. I've started spelling that out. |
| 09:07 | <annevk> | Params* |
| 09:07 | <mkwst> | annevk: But it's hideous and almost pure duplication. Without reading both the Fetch and URL specs, no one will know why they should use one or the other. |
| 09:08 | <mkwst> | annevk: I'm looking for better ideas. |
| 09:08 | <annevk> | mkwst: how do people know whether to pick enctype=application/x-www-form-urlencoded vs multipart/form-data today? |
| 09:09 | <mkwst> | annevk: I doubt most people do. |
| 09:09 | <annevk> | If they didn't files wouldn't end up on the server |
| 09:09 | <mkwst> | I meant that I expect modern frameworks to handle both. |
| 09:10 | <annevk> | That is true, but you still have to pick the non-default one to make things work |
| 09:10 | <mkwst> | Sure. And I guess the default for forms is urlencoded. |
| 09:10 | <annevk> | But yeah, I guess it's fair to say that most folks don't really understand the difference really well, since the server software tends to abstract from the submission format quite a bit |
| 09:13 | <annevk> | So your suggestion would be to either overload FormData or have some higher level of abstraction in Credentials? |
| 09:13 | <mkwst> | So, I can certainly spell out the contours of an opaque URLSearchParams object, and teach PasswordCredential to produce one. And add some helpful text in the spec that says "Hey, use this one if you need this kind of form submission, and this one if you don't." It's just very ugly and I feel bad typing it. :) |
| 09:14 | <mkwst> | I don't have much of a suggestion. We need the ability to determine the names of the username/password parameters, and we need the ability to tack on additional data to the submission. |
| 09:14 | <mkwst> | For both of those cases, something like FormData or URLSearchParams is a good fit. |
| 09:15 | <mkwst> | It would be nice if they weren't two things, honestly. |
| 09:17 | <mkwst> | One option might be to have some nicely named `toSubmittableObjectThatHasTheDataYouNeed()` method that returns either a FormData or URLSearchParams object based on an `enctype` paramater? |
| 09:17 | <mkwst> | then at least the credential-side interface would be clear. |
| 09:19 | <annevk> | That might be okay |
| 09:19 | <annevk> | I don't really see a good way of merging these |
| 09:19 | <annevk> | Just becomes ugly in some other way |
| 09:38 | <mkwst> | (Sorry, folks here demolishing my bathroom. Need to make sure they don't demolish the parts I like. :) ) |
| 09:39 | <mkwst> | *shrug* Idunno. From my perspective, they're doing much the same thing. I haven't followed them all the way through, so I'm sure they're distinct in interesting ways. |
| 09:40 | jgraham | has visions of mkwst typing in the bath as the room collapses around him |
| 09:40 | <mkwst> | It just seems strange that I'm ending up with two objects that, from the perspective of the credentials work, are indistinguishable. |
| 09:41 | <mkwst> | jgraham: Happily, the bathroom is way upstairs. I think it'd be tough to type in there; it's pretty loud at the moment. |
| 09:42 | <mkwst> | I'll go the "hide the complexity" route and switch on `enctype` for the moment, let's see how it ends up looking. |
| 09:47 | <annevk> | mkwst: I mean the only reason we're even dealing with this is because there's some legacy stuff going on |
| 09:47 | <annevk> | mkwst: that you want to account for |
| 09:47 | <annevk> | mkwst: FormData is superior for non-URL stuff |
| 09:48 | <mkwst> | annevk: Right. The goal is for this to be something that developers can layer on top of an existing system. For better or worse, that means we need annoying amounts of flexibility. |
| 09:48 | <annevk> | mkwst: URLSearchParams is useful because it does not pretend it can handle Blob, and because it can be associated with a URL object |
| 09:50 | <annevk> | mkwst: I don't really have strong opinions here but I do think that since they have different serializations, not trying to shoehorn them together is useful |
| 09:51 | <mkwst> | annevk: Sure. I don't think we should rewrite Fetch because of this API. I'm just trying to find a reasonably elegant way of building the thing I want to build. :) |
| 09:51 | <annevk> | mkwst: I think toFormData() and toURLSearchParams() would still be clearest |
| 09:52 | <annevk> | mkwst: just like <form enctype> it allows folks to make an informed choice |
| 09:52 | <mkwst> | annevk: You also wrote both specs, and deeply know what each means. :) |
| 09:52 | <mkwst> | Well, `enctype` is the choice developers make for `<form>`, right? |
| 09:53 | <annevk> | mkwst: yes |
| 09:53 | <annevk> | mkwst: this is the analogous API choice |
| 09:53 | <mkwst> | They don't have `<formdata-form>` and `<urlsearchparams-form>`. |
| 09:54 | <mkwst> | Maybe if they were spelled `MultipartFormData` and `URLEncodedFormData`... :) |
| 09:54 | <annevk> | mkwst: I don't think you can really compare it that way, given that we also have <input type=color> and such |
| 09:54 | <mkwst> | Because that's the choice folks would be making for this use case. I doubt they'd care about the remaining properties for a sign-in system. |
| 09:55 | <annevk> | mkwst: sure, it just so happens that urlencoded is used outside of forms too |
| 09:56 | <annevk> | I tried to think of something like a single method, but toFetchBody(...) and such all seem equally awful |
| 09:57 | <mkwst> | Yeah. `toFetchable` is my placeholder. It's not great. |
| 09:57 | <annevk> | Also since the best default there would be the inverse of <form enctype=> which would not be great |
| 09:57 | <annevk> | And if you require the argument you've just made the API worse |
| 09:58 | <annevk> | mkwst: perhaps FormData should have a method to convert it to URLSearchParams |
| 09:58 | <annevk> | mkwst: so you only have toFormData() |
| 09:59 | <annevk> | mkwst: and if folks really need URLSearchParams for legacy reasons, they convert it |
| 09:59 | <annevk> | mkwst: could also be URLSearchParams.from(formDataInstance) |
| 10:00 | <annevk> | mkwst: of course, you still need all the hiding slots and stuff, but don't really see a way around that |
| 10:00 | <mkwst> | Well, one way around that would be to teach Fetch how to deal with a credential object. But that has its own problems. |
| 10:01 | <annevk> | That doesn't allow for appending additional data |
| 10:01 | <annevk> | I thought that was a requirement? |
| 10:01 | <mkwst> | Right. That's one of the problems. We'd have to teach the credential object how to hold data. :) |
| 10:02 | <annevk> | Ah yes, the old we have two objects to hold data, let's add a third one |
| 10:02 | <mkwst> | And then define serialization and extraction and etc. |
| 10:02 | <mkwst> | Well, it would be _my_ data-holding object. So, obviously better. |
| 10:03 | <annevk> | I'm sure that folks who want to do exactly what you want to do would appreciate it |
| 10:03 | <mkwst> | We could also skip this whole `fetch()` dance and go back to `credential.send()`. :) |
| 10:04 | <annevk> | Yeah, and then they want referrer control, custom header control, cache bypassing, ... |
| 10:04 | <mkwst> | Well, sure. We'll build all that in. |
| 10:05 | <annevk> | Of course :-) |
| 10:06 | <mkwst> | I mean, we'll spell it all differently, of course. |
| 10:06 | <annevk> | I'm sorry the best we come up with is https://xkcd.com/927/ |
| 10:06 | <annevk> | that* |
| 10:08 | <annevk> | Also, that minute took an hour |
| 10:08 | annevk | will be more careful allocating minutes to mkwst in the future :-P |
| 10:08 | <mkwst> | Your fault for not letting me just write my own Fetch in the first place. |
| 10:08 | <mkwst> | Ok. I think `toURLSearchParams` is hideous. But I'll just type it for the moment and stop bothering you. |
| 11:53 | <annevk> | mkwst: https://github.com/whatwg/html/pull/323 |
| 13:51 | <annevk> | MikeSmith: interested in reviewing https://github.com/whatwg/html-build/pull/39? |
| 14:32 | <zcorpan_> | Domenic: friendly ping https://github.com/whatwg/html/pull/246 |
| 14:46 | <annevk> | zcorpan_: he's prolly still on vacation |
| 14:47 | <zcorpan_> | oh ok |
| 14:59 | <wanderview> | I thought he was getting back today |
| 15:06 | <zcorpan_> | MikeSmith: last change in https://www.w3.org/Bugs/Public/show_activity.cgi?id=24055 looks bogus (attachment is some .dll file) |
| 16:22 | <bblfish> | annevk: did you work on webcrypto? |
| 16:22 | <annevk> | bblfish: nope |
| 16:23 | <bblfish> | ah, where/who are the folks who did? |
| 16:23 | <annevk> | bblfish: doesn't the spec say? |
| 16:24 | <bblfish> | ah true |
| 16:24 | <bblfish> | rslevi I wonder what channel he hangs out on |
| 16:25 | <annevk> | Hmm, either Twitter refuses to email me some email change confirmation email while claiming they did send it or Gmail refuses to show it |
| 16:25 | <annevk> | bblfish: Twitter |
| 16:27 | <bblfish> | ah thanks. |
| 16:31 | <bblfish> | ( been working on improving the web-crypto interface for scala-js https://github.com/bblfish/scala-js-dom/blob/fix-generate-key-api/src/main/scala/org/scalajs/dom/crypto/Crypto.scala ) |
| 17:28 | <rniwa> | Ms2ger: yt? |
| 17:28 | <rniwa> | annevk: yt? |
| 17:28 | <Ms2ger> | Just for a few more minutes |
| 17:29 | Ms2ger | should make it back into the kitchen by the time his water boils |
| 17:48 | <bblfish> | annevk: I opened an issue the other day for Fetch https://github.com/whatwg/fetch/issues/156 |
| 17:48 | <bblfish> | I'll also be submitting my Fetch to scala-js-dom lib, sometime this week. |
| 17:56 | <annevk> | bblfish: yeah I looked at that and that doesn't seem like something we'll address anytime soon |
| 17:56 | <annevk> | bblfish: the headers to be transmitted are in the network stack which is mostly post-Fetch |
| 17:57 | <annevk> | bblfish: although it's all a bit gobbled up admittedly since the standards are a bit post-implementation |
| 18:00 | <bblfish> | yes, i suppose Http Signature needs a lot more support and implementations before it makes sense to do that engineering. In the meantime we need to work out what to sign. |
| 18:01 | <bblfish> | otherwise there's another catch22. There are a lot of catch-22s when dealing with authentication. That's why however bad it is TLS-crypto at least works. |
| 18:08 | <annevk> | For some reason https://tools.ietf.org/html/draft-cavage-http-signatures is not loading, the -00 draft seemed very light on detail |
| 18:08 | <bblfish> | it's version -05 annevk |
| 18:08 | <bblfish> | this one https://tools.ietf.org/html/draft-cavage-http-signatures-05 |
| 18:11 | <annevk> | tools.ietf.org seems very slow for some reason |
| 18:12 | <annevk> | That draft seems to sorta skip over justification for why it's a good idea to begin with |
| 18:13 | <bblfish> | There are quite a few services that currently do stuff like that, such as Amazon cloud, and others. |
| 18:17 | <bblfish> | Amazon has a signature based auth mechanism http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html |
| 18:18 | <bblfish> | OCLC HMAC Auth https://www.oclc.org/developer/develop/authentication/hmac-signature.en.html |
| 18:18 | <bblfish> | Akamai https://developer.akamai.com/introduction/Client_Auth.html |
| 18:19 | <bblfish> | Lindsay http://progrium.com/blog/2012/12/17/http-signatures-with-content-hmac/ |
| 18:19 | <bblfish> | But yes, it may be that better justification would help |
| 18:43 | <JakeA> | annevk: is there such a thing as a guide to writing web standards? As in, something that explains the ideal structure of a standards doc, when you'd queue a task, how to reference things in other specs etc |
| 18:46 | <annevk> | JakeA: no |
| 18:46 | <annevk> | JakeA: there's bits and pieces |
| 18:47 | <JakeA> | annevk: if we're wanting to increase diversity here, feels like there should be. I'll keep it in mind as a possible 2016 thing. |
| 18:48 | <annevk> | JakeA: I agree that we need it |
| 18:49 | <annevk> | JakeA: I'd like to improve the foundations a bit as well as both HTML and IDL are somewhat shoddy to build on |
| 18:49 | <annevk> | JakeA: and I have some kind of vision as to how things should be, but getting there takes tim |
| 18:49 | <annevk> | time* |
| 18:50 | <wanderview> | it would be great even to have someplace to capture common mistakes... so every time someone experiences mutters "this is a terrible spec", they can add why to the "don't do this" list |
| 18:50 | <wanderview> | ^experiences^experienced |
| 18:51 | <JakeA> | annevk: well, we've got a couple of people in dev rel wanting to get into spec stuff, so that might be a good opportunity to figure out all the stumbling blocks |
| 18:51 | <JakeA> | annevk: anyway, I'll pick it up with you in 2016. Just thinking out loud now. |
| 18:52 | <wanderview> | JakeA: did you ever have a chance to look and see when propagating the intercepted URL will be implemented in chrome? |
| 18:53 | <annevk> | Domenic: have you perhaps not synced https://github.com/whatwg/html-build with the build server? |
| 18:53 | <annevk> | Domenic: and is that why https://github.com/whatwg/html/issues/324 is a problem? |
| 18:53 | <Domenic> | annevk: it should be automatic |
| 18:53 | <annevk> | JakeA: sounds great |
| 18:53 | <Domenic> | The cache is not cleared though |
| 18:54 | <JakeA> | wanderview: *scratches head* I'm not sure what that means, give me a clue :D |
| 18:54 | <Domenic> | So if clearing the cache is necessary that means we shouldn't be caching something that we're currently caching |
| 18:54 | <JakeA> | Is this the CSS base url thing? |
| 18:54 | <wanderview> | JakeA: https://github.com/whatwg/fetch/pull/146 |
| 18:54 | <JakeA> | (brb catching a train) |
| 18:54 | <wanderview> | np |
| 18:56 | <annevk> | Domenic: hmm, there's no commit hook for html-build |
| 18:56 | <Domenic> | annevk: zcorpan: on a plane at the moment, will get to reviews and build stuff when I land and get to the hotel hopefully (BlinkOn) |
| 18:56 | <Domenic> | Hmm |
| 18:56 | <Domenic> | Oh I think it's updated with HTML |
| 18:56 | <annevk> | Domenic: ah yes, have fun |
| 18:56 | <annevk> | Domenic: this can wait another week, I'm sure |
| 18:57 | <Domenic> | Every HTML push pulls from HTML-build |
| 18:57 | <Domenic> | Meh I figure BlinkOn week is work week so I'll get at least some stuff done |
| 18:59 | <annevk> | I removed the entity stuff from the cache manually |
| 19:00 | <annevk> | "Updating entities database (this always takes a while)..." oh yes you do |
| 20:55 | <bblfish> | annevk: I explored how we can work without the capabilities proposed in Fetch issue 156 in https://github.com/solid/solid-spec/issues/52 |
| 20:56 | <bblfish> | we essentially need just a JS-Date header |
| 20:57 | <bblfish> | ( this does not exclude other groups having use cases needing the capabilities of issue 56 ) |