| 04:43 | <Hixie> | zcorpan: have them mail me |
| 06:41 | <Joser> | hello |
| 06:43 | <Ms2ger> | Bye |
| 08:24 | <MikeSmith> | zcorpan: sorry if I seemed overly dismissive in my response to that validator bug report |
| 08:25 | <zcorpan> | MikeSmith: no problem |
| 08:25 | <MikeSmith> | the context is that I was going through validator bugs this weekend and trying to resolve some of the stale onece |
| 08:25 | <MikeSmith> | *ones |
| 08:25 | <MikeSmith> | that is, ones that I think have little chance of ever getting implemented |
| 08:25 | <MikeSmith> | and that bug seems like one of those |
| 08:26 | <MikeSmith> | what I really want to do is just move the legacy validator to validator.w3.org/classic or something |
| 08:27 | <MikeSmith> | and completely remove the HTML5-checking from it |
| 08:27 | <MikeSmith> | and instead just move the validator.nu-based validator to validator.w3.org |
| 08:28 | <MikeSmith> | then the kinds of problems like in that bug report disappear |
| 08:28 | <jgraham> | "classic" does rather strongly suggest "classic car", which might not give quite the right impression. |
| 08:28 | <MikeSmith> | and I could focus just on making the vnu validator as good as it should be |
| 08:29 | <jgraham> | I would make all sorts of serious suggestions |
| 08:29 | <MikeSmith> | jgraham: it's better than "old" or "legacy" |
| 08:29 | <jgraham> | But really I just want it to be /steampunk |
| 08:29 | <MikeSmith> | heh |
| 08:30 | <MikeSmith> | antique |
| 08:30 | <MikeSmith> | emeritus |
| 08:31 | <Ms2ger> | "brocante" is apparently translated as "junk" |
| 08:57 | <zcorpan> | MikeSmith: makes sense |
| 11:27 | <jgraham> | zcorpan: Thanks for finishing that review |
| 11:27 | <zcorpan> | np |
| 11:29 | <jgraham> | Should register arewereviewedyet.com and plot number of open pull requests against time |
| 11:30 | <jgraham> | Actually it would be a pretty nice idea to make a web-platform-tests status dashboard |
| 11:31 | <jgraham> | With # open pull requests |
| 11:31 | <jgraham> | Some measurements of test coverage |
| 11:31 | <jgraham> | Probably some other stuff |
| 11:33 | jgraham | wonders what a "branded future" is |
| 11:34 | <jgraham> | Apart from social commentary |
| 11:40 | <Ms2ger> | zcorpan, jgraham, any of you want to merge? :) |
| 11:41 | <zcorpan> | "Server reply: Merging pull request failed (you are not allowed to merge this pull request)" |
| 11:41 | <Ms2ger> | Boo. |
| 11:41 | <zcorpan> | merging in github worked |
| 11:41 | <Ms2ger> | Ah |
| 11:41 | <jgraham> | That button doesn't work :) |
| 11:42 | <Ms2ger> | Merging in critic is known-broken |
| 11:42 | <jgraham> | I don't know why |
| 11:42 | <Ms2ger> | I don't know why the button is still there ;) |
| 11:43 | <jgraham> | Ms2ger: BEcause I haven't dared revert to the version I put in critic-critic yet :) |
| 11:43 | <jgraham> | s/revert/switch/ |
| 11:43 | <Ms2ger> | So you're asking the critics to review your critic which you aren't using to critic? |
| 11:44 | <jgraham> | Exactly |
| 11:44 | <Ms2ger> | Aha |
| 11:44 | Ms2ger | goes back to Featherweight Java |
| 12:05 | <asmodai> | Mmm, if I see Opera and Firefox send out a GET request for a favicon.ico and Chrome does not do it, can I assume Chrome's behaviour is buggy? (Empty caches and all that, so it ought to fetch a clean copy.) Or could a 302 redirect cause it to be missing out on sending this GET out? Not sure what the expected behaviour is in that case. |
| 12:06 | <asmodai> | I would still expect it to send out a GET for the icon, even if it gets redirected though. |
| 12:52 | <annevk> | jgraham: branding is the way "if /x/ is an Element" type of checks work |
| 12:52 | <annevk> | jgraham: it's not very explicit in current specifications |
| 12:52 | <annevk> | jgraham: here's a gist explaining it https://gist.github.com/wycats/89b2a49a3431b04e88c7 |
| 13:03 | <zcorpan> | so CaretPosition#getClientRect would return a zero-width "rectangle"? |
| 13:06 | <jgraham> | annevk: I rather suspect "work" in that sentence has nothing to do with actual implementations |
| 13:06 | <annevk> | jgraham: sorry, will work |
| 13:06 | <jgraham> | Or rather, I doubt the contents of that gist are like what implkementations will do |
| 13:07 | <jgraham> | And I don't really understand what point it's trying to make |
| 13:11 | <annevk> | But you understand what I meant now? |
| 13:13 | <jgraham> | Not really, but I mgith be missing the context |
| 13:13 | <jgraham> | Although certainly using something that appears to be a recently-coined term doesn't make things clearer |
| 13:14 | <annevk> | It's a ES6 concept which I think es-discuss is quite familiar with and I was not until recently, but it helps explaining part of how host objects currently work. |
| 13:15 | <annevk> | It was also a big part of the discussion leading up to futures so you might find it worth your time going through that. |
| 13:41 | <hsivonen> | huh. nothing on w3cmemes about the recent public-html-media thread |
| 13:42 | <Ms2ger> | People still read that? |
| 13:43 | hsivonen | reads both public-html-media and w3cmemes |
| 13:50 | <odinho> | hsivonen: So you seem to be the man to make it then :] |
| 13:50 | <Ms2ger> | zcorpan++ |
| 13:51 | <zcorpan> | Ms2ger: hmm? |
| 13:51 | <Ms2ger> | Having an editor for cssom again is nice |
| 13:51 | <zcorpan> | ah |
| 13:52 | <MikeSmith> | Ms2ger: who's editing CSSOM? |
| 13:52 | <odinho> | Guessing zcorpan based on the increment. |
| 13:53 | <zcorpan> | yes |
| 13:55 | <MikeSmith> | great |
| 13:57 | <annevk> | zcorpan: is there a version history link available? |
| 13:57 | <Ms2ger> | https://dvcs.w3.org/hg/csswg? |
| 13:58 | <annevk> | :/ |
| 14:18 | <zcorpan> | i'm not really getting along with glenn's build system |
| 14:18 | <annevk> | zcorpan: why don't you start from before he messed up my system? |
| 14:21 | <zcorpan> | i guess that would involve kicking glenn out as editor and he said he wanted to continue to edit |
| 14:25 | <reyre__> | anyone know what the purpose of keeping track of a 'language stack' in the webvtt cue text parsing rules is? http://dev.w3.org/html5/webvtt/#webvtt-cue-text-parsing-rules |
| 14:32 | <zcorpan> | reyre__: all webvtt nodes get an "applicable language" assigned from the top of the stack |
| 14:32 | <annevk> | zcorpan: :/ |
| 14:33 | <zcorpan> | reyre__: so that :lang() works |
| 14:34 | <reyre__> | ah okay, i see that now. missed that point |
| 14:34 | <reyre__> | thanks zcorpan :) |
| 14:35 | <reyre__> | zcorpan: does the applicable language apply for text node objects ? or just internal node objects ? |
| 14:35 | <reyre__> | looks like only internal node objects |
| 14:36 | <zcorpan> | reyre__: http://dev.w3.org/html5/webvtt/#dfn-attach-a-webvtt-internal-node-object |
| 14:37 | <reyre__> | zcorpan: okay sounds good, thanks :) |
| 14:43 | <zcorpan> | <lang> is not tested in opera's testsuite |
| 14:59 | <Ms2ger> | Yay, PR 100 |
| 15:51 | <hsivonen> | MikeSmith: whoa. the Html4Assertions class ended up being pretty short |
| 16:05 | <TabAtkins> | jgraham: I think "branding" is a spec concept right now, but as soon as we have Symbols in JS, it'll be a real thing. Basically just means something that has been blessed by the runtime as a real thing, rather than having to use duck-typing to tell whether it's a Future or not. |
| 16:06 | <TabAtkins> | zcorpan: I wouldn't worry about glenn's assertions that he wants to continue to edit. He hasn't done any non-trivial editing in a year, so it's on him to prove that he's actually worth something to the spec. |
| 16:16 | <jgraham> | TabAtkins: Yeah, I get the idea. It's bolt-on typing. |
| 16:16 | <TabAtkins> | Yes. |
| 16:17 | <TabAtkins> | A form of nominative typing in a language without any explicit way to handle it. |
| 16:26 | <wycats__> | I should have a lot more on JSIDL soon |
| 16:26 | <TabAtkins> | wycats__: Ooh, intrigued. Got any pointers? |
| 16:26 | <wycats__> | It's important to think of JSIDL's types as coercion rules not typed |
| 16:26 | <wycats__> | Types |
| 16:27 | <wycats__> | http://wycats.github.io/jsidl/jsidl.html |
| 16:27 | <dglazkov> | good morning, Whatwg! |
| 16:27 | <wycats__> | Please don't bikeshed yet. This is super early and missing a ton of stuff |
| 16:27 | <wycats__> | Working with annevk and others |
| 16:30 | <dglazkov> | wycats__: I don't like the fonts |
| 16:30 | <dglazkov> | oh you said _don't_ bikeshed |
| 16:31 | <dglazkov> | :P |
| 16:38 | <annevk> | Java in JavaScript: http://int3.github.io/doppio/about.html Should've seen that coming I suppose. |
| 16:39 | <TabAtkins> | Hey, if crazies are still gonna write Java applets, might as well run them without Java. |
| 16:40 | <Hixie> | MikeSmith: there's a Version field in Bugzilla, you could create a "legacy" version and move the old bugs to that |
| 16:45 | <annevk> | So http://wikileaks.org/Transcript-Meeting-Assange-Schmidt was a pretty good read |
| 16:46 | <manu-db> | TabAtkins, annevk: When you get a sec, could you sanity check that we're defining the Futures stuff correctly via the WebIDL in the JSON-LD API (ignore the big red issue marker, it no longer applies): http://www.markus-lanthaler.com/tmp-futures/json-ld-api/#the-jsonldprocessor-interface |
| 16:49 | <TabAtkins> | manu-db: Will do. |
| 16:50 | <TabAtkins> | manu-db: I think you need to specify that the returned future is initially pending. |
| 16:51 | <manu-db> | TabAtkins: yup, ok, thanks. |
| 16:51 | <TabAtkins> | Otherwise, I'll defer to annevk to tell you whether your use of terminology is correct and sufficient. (I hope it is, because that's a nice easy way to talk about futures.) |
| 16:52 | <annevk> | manu-db: you need to create a new future, return it, and say that the remaining steps have to be run asynchronously |
| 16:52 | <annevk> | manu-db: and then at some point you invoked the future's associated resolver's reject and resolve algorithms |
| 16:52 | <annevk> | manu-db: in those asynchronous steps |
| 16:53 | <annevk> | TabAtkins: pending is the default state of a new future, so that's not needed |
| 16:53 | <manu-db> | annevk: You're saying that we should document that in the spec, right? That is, you're not telling me how futures work, you're saying that we need to make it clear to the developer that those are the steps that are going to occur when they make the call? |
| 16:54 | <annevk> | manu-db: yes you need to write that in the specification so implementors know what to do |
| 16:55 | <manu-db> | annevk: ok, we'll do that, then. Seems a bit strange though, as the Futures spec should probably say that? |
| 16:55 | <TabAtkins> | annevk: It would be great if we could abstract that away and just say "reject the future with [value]" or whatever. Is there a reason we need to be specific about "the future's associated resolver's reject algorithm"? |
| 16:55 | <annevk> | manu-db: say what? |
| 16:55 | <TabAtkins> | Each future has only one resolver, after all. |
| 16:55 | <manu-db> | annevk: what TabAtkins is saying. |
| 16:56 | <annevk> | I suppose we could provide a shortcut for specifications, but the idea is that when you create a future you get hold of a resolver object you control and that is not exposed to the outside world |
| 16:56 | <annevk> | and that resolver object is what you use to influence the state of the future |
| 16:56 | <manu-db> | annevk: Unless I don't understand how the resolver works (which could very well be true), it seems like what you suggested that we put into the JSON-LD API spec is boilerplate text that should probably exist in the WHATWG DOM spec. |
| 16:56 | <TabAtkins> | Yes, but that can all be implicit, since we're in spec land. |
| 16:56 | manu-db | nods. |
| 16:57 | <annevk> | I'm not entirely convinced that hiding the conceptual model is a net positive |
| 16:57 | <manu-db> | if we don't make it implicit, then the implication is that all the specs that use Futures will just repeat that same line, no? |
| 16:57 | <TabAtkins> | It's just understood that, when a spec creates a future, it has access to its resolver. Then we can just operate on the future's state directly. |
| 16:58 | <manu-db> | annevk: It's not really hiding the conceptual model, it's that people should probably understand how a Future works and if they don't, they should read the spec that defines futures (or a tutorial) |
| 16:58 | <manu-db> | annevk: Most APIs layered on top of the DOM don't get into the gory details of the conceptual model of the DOM, afaik. |
| 16:59 | <manu-db> | TabAtkins, annevk: In this particular case, I'm fine with being a little more explicit about how the API works in the JSON-LD API since Futures are kinda new-ish to developers. |
| 16:59 | <annevk> | manu-db: gory? hah |
| 16:59 | <annevk> | manu-db: but yeah, I suppose we'll add some boilerplate shortcuts |
| 16:59 | <TabAtkins> | annevk: The kind of text you're saying we need to use to invoke a future is indeed gory. ^_^ |
| 17:00 | <annevk> | The futures spec itself uses it consistently too |
| 17:00 | <annevk> | It's not that bad really |
| 17:00 | <manu-db> | annevk, TabAtkins: We'll try to write some text explaining the design of the API and I'll run it by both of you once we're done. |
| 17:01 | <TabAtkins> | It... really is. From your history with writing specs, it seems you're just bad at seeing stuff as gory. ^_^ |
| 17:01 | manu-db | thanks annevk, TabAtkins... disappears. |
| 17:01 | <annevk> | manu-db: the most important bits however are saying that you return a new future and that the remaining steps are to be run asynchronously |
| 17:01 | manu-db | nods. |
| 17:01 | <SteveF> | Hixie: would appreciate an answer to this: http://krijnhoetmer.nl/irc-logs/whatwg/20130418#l-611 |
| 17:01 | <TabAtkins> | Yeah, that part seems reasonable and necessary. |
| 17:02 | <annevk> | reasonable? come on TabAtkins |
| 17:02 | <TabAtkins> | ? |
| 17:03 | <annevk> | and the ad-hominem seems out-of-place too |
| 17:04 | <TabAtkins> | Uh, dude, back up a bit. |
| 17:05 | <TabAtkins> | I'm saying that I think you have a problem with seeing complexity in your own specs. This is not an ad hominem attack. Please take it as a gentle criticism, and a request that you keep boilerplate minimization as a goal for specs calling into your own in the future. |
| 17:08 | <TabAtkins> | As a simple example, "invoke the future's associated resolver's reject algorithm with [value]" is unacceptable boilerplate for a feature this simple. "Reject the future with [value]." is acceptable - both easy to write, and easy for people (implementors and authors) to read. |
| 17:11 | <annevk> | You probably want. Let f be future and r its associated resolver. Run r's reject with [value [and the synchronous flag set]] |
| 17:11 | <annevk> | This reminds me of a bug I need to comment on though... |
| 17:13 | <jgraham> | TabAtkins: I guess annevk already said this, but the second form seems suboptimal to me because it isn't totally clear which algorithm you are invoking |
| 17:13 | <TabAtkins> | I don't want any of that. That's still far more complexity than I should need to specify for a spec, where it's assumed that I have access to the resolver for a future I've created in an earlier step. |
| 17:13 | <TabAtkins> | jgraham: There's only three algorithms: accept, resolve, and reject. I'm unsure how it could be unclear which is being invoked when you say "reject the future". |
| 17:14 | <jgraham> | "reject the future" doesn't obviously invoke *any* of the algorithms |
| 17:14 | <TabAtkins> | annevk: I'd like a paragraph in the spec that says something like, "To <dfn>reject a future</dfn>, let f be future and r its assocated resolver...". |
| 17:14 | <Hixie> | SteveF: do you mean, how should changes that the w3c has made in its fork of HTML be documented? |
| 17:15 | <TabAtkins> | Then I can just say "Reject the future with [value]", and link to your anchor. |
| 17:15 | <Hixie> | SteveF: or do you mean, how should problems in the HTML standard be reported? |
| 17:15 | <jgraham> | Righ, if DOM defines the meaning of "reject the future" then things are different |
| 17:15 | <TabAtkins> | jgraham: You'll have to explain to me what confusion you're seeing. |
| 17:15 | <TabAtkins> | jgraham: Well, obviously. ^_^ |
| 17:16 | <jgraham> | TabAtkins: I'm seeing the confusion that you are trying to invoke a definition that doesn't yet exist :p |
| 17:16 | <TabAtkins> | Pedant. ^_^ |
| 17:16 | <TabAtkins> | This is spec land, I can just assume that an appropriate definition exists for me to invoke. |
| 17:18 | <jgraham> | Not if you want to write good specs :) |
| 17:18 | <SteveF> | hixie: I mean the former |
| 17:18 | <Hixie> | SteveF: the way that i used to do it in the whatwg spec seems like the simplest solution |
| 17:19 | <Hixie> | SteveF: just have a section in the intro that lists every intentional difference |
| 17:19 | <Hixie> | and the rationale |
| 17:19 | <Hixie> | SteveF: that way people could tell which were intentional and which were not |
| 17:19 | <Hixie> | SteveF: and what the rationales were |
| 17:20 | <annevk> | TabAtkins: I'd still like to see how you generalized so quickly from one example which I haven't even thought much about yet since there's no external consumers yet to me having a general habbit of doing the wrong thing. |
| 17:20 | <SteveF> | hixie: OK will discuss with the editor team - thanks |
| 17:23 | <TabAtkins> | annevk: I'm generalizing from my experiences with CORS, which I still find impenetrable despite my best efforts. :/ |
| 17:23 | <annevk> | TabAtkins: the problem with CORS is that CSS doesn't have "fetch". And without "fetch" trying to understand CORS is like going way beyond where you are today. |
| 17:24 | <TabAtkins> | I can accept that, sure. |
| 17:24 | <annevk> | TabAtkins: http://fetch.spec.whatwg.org/ should address that, though beware, it has no convenient hooks yet either |
| 17:24 | <Hixie> | anyone got IE around? what does it alert in http://damowmow.com/playground/demos/cross-iframe-scripting/001.html ? |
| 17:24 | <Hixie> | annevk: doesn't it have the old HTML "fetch" still? |
| 17:24 | <annevk> | Hixie: CSS could use the HTML definitions, sure |
| 17:25 | <Hixie> | annevk: problem solved :-) |
| 17:25 | <annevk> | Hixie: oh you mean that specification? Yeah I have the mapping defined somewhere under "Legacy". I still haven't really figured out the right abstractions. |
| 17:25 | <TabAtkins> | Tell me where to define it, and I'll get it done |
| 17:26 | <Hixie> | annevk: you should just make that the actual hook. There's no way I'm updating HTML to use another hook, that's way too risky, and way too much work, for way too little benefit. |
| 17:26 | <Hixie> | annevk: and it's a nice simple API. |
| 17:26 | <annevk> | Hixie: but the API doesn't handle CORS |
| 17:26 | <Hixie> | annevk: right, there's the separate hook if you want CORS. |
| 17:27 | <annevk> | Hixie: and the API cannot be used by XHR, and the new navigation controller stuff that's coming |
| 17:27 | <Hixie> | annevk: you either do a "fetch", or a "potentially CORS-enabled fetch". |
| 17:27 | <Hixie> | annevk: why not? |
| 17:27 | <Hixie> | (what is a "navigation controller"?) |
| 17:28 | <annevk> | Hixie: https://github.com/slightlyoff/NavigationController/ |
| 17:29 | <annevk> | Hixie: and your current hooks have overlaps with e.g. the same-origin flag that's the same as "No CORS", fail |
| 17:29 | <annevk> | Hixie: and don't sufficiently distinguish between credentials and CORS |
| 17:30 | <Hixie> | annevk: i wouldn't describe that as "stuff that's coming" until it's, you know, actually discussed on a public list... |
| 17:30 | <annevk> | Hixie: what's the difference between a public list and a public repo? |
| 17:30 | <annevk> | Hixie: it's been announced on a public list |
| 17:30 | <Hixie> | same thing that's wrong with creating a new mailing list |
| 17:30 | <Hixie> | people aren't on it |
| 17:32 | <TabAtkins> | annevk: Unrelated discussion - I'm finding it hard to follow exactly, but do Futures recursively resolve? That is, in the following code: |
| 17:32 | <annevk> | Well, there's some set of people that prefer working on it this way. And if that's the way they prefer to getting it done, that's the way it'll happen. |
| 17:32 | <jgraham> | (actually NavigationController was a private repo for a long time which is extremely distastful) |
| 17:33 | <TabAtkins> | getFuture().then(function(){ return new Future(function(r) { r.accept(new Future(...)); })}); |
| 17:33 | <annevk> | Hixie: also, your current hooks are extremely hard to reason about with respect to the Origin header and the implications on security. And actually have several bugs. E.g. a cross-origin redirect to a javascript: URL will be CORS-same-origin... |
| 17:33 | <Hixie> | annevk: or not happen, as the case may be :-) |
| 17:34 | <TabAtkins> | (In other words, .then() returns a future for a future.) |
| 17:34 | <slightlyoff> | Hixie: that's the next step |
| 17:34 | <TabAtkins> | Does it resolve to just a future, or to the future-of-a-future's resolved value? |
| 17:34 | <slightlyoff> | Hixie: getting the design to a point where it's not a total shit-show is Step 1 |
| 17:34 | <annevk> | TabAtkins: you need to use resolve for that, not accept |
| 17:35 | <Hixie> | slightlyoff: just make sure you don't present a fait accompli... people always feel they need to change proposals before they're willing to adopt them. that's why i encourage people to put their shit shows in public first. :-) |
| 17:35 | <slightlyoff> | Hixie: designs need to hang together |
| 17:35 | <TabAtkins> | annevk: I used accept for a reason, specifically so I could ask the question that I did. |
| 17:35 | <Hixie> | slightlyoff: designs are not what should be presented first |
| 17:35 | <slightlyoff> | Hixie: I'm more interested in "good" than "inclusive". The standards process has plenty of room for the later |
| 17:35 | <annevk> | TabAtkins: but you also said "resolve" :-) |
| 17:36 | <Hixie> | slightlyoff: if you're interested in "adopted", then "inclusive" is more important than "good" |
| 17:36 | <slightlyoff> | Hixie: here's the new outline of the current design: https://github.com/slightlyoff/NavigationController/blob/master/explainer.md |
| 17:36 | <TabAtkins> | Man, whatever the generic term is for "has a value that isn't an error". ^_^ |
| 17:36 | <TabAtkins> | "fulfilled"? |
| 17:36 | <Hixie> | slightlyoff: before we discuss design proposals, we should discuss the problem. on a public list. |
| 17:37 | <annevk> | TabAtkins: "accepted" |
| 17:37 | <TabAtkins> | So, "accepted" just means that it's done, regardless of whether it was accepted with r.accept() or r.resolve()? |
| 17:38 | <annevk> | TabAtkins: yeah, at some point resolve runs through accept |
| 17:38 | <TabAtkins> | Kk. |
| 17:38 | <annevk> | TabAtkins: if it wasn't a future |
| 17:38 | <annevk> | well thenable |
| 17:38 | <TabAtkins> | So returning a future of a future from a .then() callback just unwraps one level of future, not both. |
| 17:38 | <Hixie> | jgraham: i don't know what to do with https://www.w3.org/Bugs/Public/show_bug.cgi?id=17155 |
| 17:39 | <annevk> | Hixie: the problems with the current offline solution have been discussed to death though and have been used as input to this design. |
| 17:40 | <annevk> | TabAtkins: if you use .accept, yes, if you use, .resolve, no |
| 17:40 | <Hixie> | annevk: every discussion i've seen about the problems with the many current offline solutions have (a) not agreed about what those problems are, and (b) not actually been about offline, typically. |
| 17:41 | <jgraham> | Hixie: Nor do I really :) I don't have any testcases to hand other than the one in the first comment |
| 17:42 | <TabAtkins> | annevk: That response is confusing, so to be absolutely clear, let me rephrase in a simpler way. Assume that "Future.of(a)" is equivalent to "new Future(function(r) { r.accept(a); })". |
| 17:42 | <Hixie> | jgraham: k |
| 17:42 | <TabAtkins> | Then, in this scenario: "getFuture().then(function() { return Future.of(Future.of(5)); }).then(function(v) { console.log(v); });" |
| 17:43 | <TabAtkins> | The log will show a Future containing 5, not 5 itself, yes? |
| 17:43 | <slightlyoff> | Future.of() is a terrible API name, BTW |
| 17:43 | <slightlyoff> | I hope we haven't accepted that (har har) |
| 17:43 | <TabAtkins> | slightlyoff: Disagree, but neither here nor there. ^_^ |
| 17:43 | <annevk> | TabAtkins: yes |
| 17:43 | <TabAtkins> | annevk: Okay, cool. |
| 17:45 | <TabAtkins> | annevk: That's my preferred answer, but it's also different from Promises/A+ at the moment, which I think recursively unwraps in its resolve algorithm until it hits a non-thenable. |
| 17:45 | <Hixie> | jgraham: i guess part of my confusion is that as far as i can tell, the spec already says this is sync |
| 17:45 | <annevk> | Hixie: I think the main problem is that there are many different problems and developers need lower-level primitives to tackle them. |
| 17:45 | <TabAtkins> | (And .then() invokes the resolve algorithm on its callback's return value.) |
| 17:45 | <jgraham> | Recursive unwrapping is weird magic |
| 17:45 | <TabAtkins> | jgraham: Agreed, but some people don't. :/ |
| 17:45 | <annevk> | Hixie: they cannot all be tackled within the constraints of "appcache". |
| 17:45 | <TabAtkins> | I just want a damned monad. Is that so much to ask? |
| 17:45 | <Hixie> | annevk: sure, but then we should document those problems. where was that done? how are we going to evaluate the proposals? |
| 17:45 | <Hixie> | annevk: i didn't mention appcache |
| 17:46 | <annevk> | TabAtkins: again, Promises/A+ would use r.resolve() |
| 17:46 | <annevk> | Hixie: have you not read public-webapps in a while? |
| 17:47 | <TabAtkins> | annevk: That's not what I asked. |
| 17:47 | <Hixie> | annevk: unless something happened since friday, i think i'm up to date |
| 17:48 | <Hixie> | jgraham: oh, nm, i see where it says it's async... |
| 17:49 | <annevk> | Hixie: documentation is in http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html and such |
| 17:50 | <TabAtkins> | annevk: The only relevance of .accept() vs .resolve() in my question was to construct the nested future. That's not important here, just assume that a nested future can be created somehow. |
| 17:50 | <annevk> | TabAtkins: so Promises/A+ does not have a concept of accept() so it will of course always do resolve() and unwrap endlessly... What am I missing? |
| 17:50 | <TabAtkins> | annevk: My point was about returning a nested future from the .then callback. |
| 17:50 | <TabAtkins> | Since .then(), even in DOM Futures, *does* use resolve semantics for its callback's return value. |
| 17:50 | <Hixie> | annevk: yeah, that discussion was great, but then it just stopped |
| 17:51 | <annevk> | Hixie: right, people moved to working on proposals |
| 17:51 | <annevk> | TabAtkins: right |
| 17:52 | <Hixie> | annevk: there was a proposal in that e-mail, that's where it should be... |
| 17:52 | <TabAtkins> | annevk: Are you just saying that it's impossible to even construct a nested future using only Promises/A+ stuff, so that's why they go ahead and unwrap nested futures when they receive one? |
| 17:52 | <annevk> | TabAtkins: yes |
| 17:52 | <TabAtkins> | Okay, makes sense. |
| 17:53 | <Hixie> | annevk: (and i'm not convinced that this problem description really is the right starting point. it seems very focused on appcache, rather than on what the actual problem is.) |
| 17:53 | <TabAtkins> | I was just checking that my preferred interpretation was what was happening, and if so, that it was a willful break from A+, not an unintentional one. |
| 17:53 | <TabAtkins> | So I'm satisfied now. ^_^ |
| 17:53 | <annevk> | Hixie: I think the actual problem is lack of primitives so people can build their "own appcache". |
| 17:54 | <annevk> | TabAtkins: it's not breaking Promises/A+. It's just a feature they don't have. |
| 17:54 | <Hixie> | annevk: that's not a problem, that's the start of a solution. |
| 17:54 | <TabAtkins> | annevk: Well, it does mean that if you receive a promises/a+ promise, chain off of it with .then(), and return a nested future, it'll have a different result than doing the same thing starting from a dom future. |
| 17:54 | <annevk> | Hixie: fair enough. The problem is too much constraints. |
| 17:55 | <annevk> | TabAtkins: it all depends on how you create the nested future really |
| 17:55 | <TabAtkins> | annevk: Hm, explain? |
| 17:56 | <Hixie> | annevk: problems i've seen are things like "we have a one-page web app and we'd like it to load instantly if the user comes back to it" |
| 17:57 | <Hixie> | annevk: (that particular one is handled fine by the appcache, and to a lesser extent, the http cache) |
| 17:57 | <Hixie> | annevk: (i've seen other ones that aren't handled by either appcache or http) |
| 17:57 | <Hixie> | annevk: that's what i mean by problem |
| 17:58 | <Hixie> | jgraham: k well i had a go at fixing 17155, dunno how good it is |
| 17:58 | <Hixie> | mounir: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=11937 |
| 18:01 | <annevk> | TabAtkins: actually, now I'm not sure anymore |
| 18:01 | <jgraham> | Hixie: Cool, thanks |
| 18:01 | <annevk> | TabAtkins: too late for this :/ |
| 18:04 | <annevk> | TabAtkins: okay, so the unwrapping works by invoking .then() on the future returned. What that future returns however is up to the implementation of that future. |
| 18:06 | <annevk> | TabAtkins: I don't see what part of http://promises-aplus.github.io/promises-spec/ is violated though |
| 18:07 | <annevk> | TabAtkins: it does not forbid fulfilling (in terms of A+) a promise with a promise |
| 18:07 | <SteveF> | Hixie: since there is a commit feed that lists every change https://github.com/w3c/html/commits/master would it not make sense to ensure that adequate exaplanation pointers are provided in the commit info rather than having to rewrite stuff? |
| 18:08 | <Hixie> | SteveF: simpler for what purpose? |
| 18:08 | <slightlyoff> | TabAtkins: if you feel that's a real issue, I'd like to see code that shows why |
| 18:08 | <slightlyoff> | (other than instanceof users) |
| 18:08 | <Hixie> | SteveF: i can't tell from that feed what's going on. For example, it credits me for a bunch of stuff but I've never checked anything into that repo. |
| 18:08 | <slightlyoff> | TabAtkins: |
| 18:09 | <slightlyoff> | ugg, typing faaaaail. |
| 18:09 | <TabAtkins> | slightlyoff: If I feel *what* is a real issue? Recursive assimilation, or lack of such? |
| 18:09 | <annevk> | Hixie: with respect to fetch; basically the current abstractions from HTML make it extremely hard to reason about what is going to happen. That's my main beef with them |
| 18:10 | <slightlyoff> | Recursive assimilation (if I understand you correctly) happens when you use .resolve() |
| 18:10 | <Hixie> | annevk: why? |
| 18:10 | <SteveF> | Hixie: for purpose of listing differences : a filtered feed could be made that lists only differences (for example) |
| 18:10 | <slightlyoff> | TabAtkins: or did I miss the case? |
| 18:10 | <slightlyoff> | TabAtkins: anyhow, send me mail. Need to eat. |
| 18:10 | <TabAtkins> | slightlyoff: I'm worrying about the value returned by .then()'s callback. That's processed with resolve semantics. |
| 18:11 | <Hixie> | SteveF: i can't tell what is different from that feed. |
| 18:11 | <Hixie> | SteveF: sometimes the diffs it credits to me are not what i did. |
| 18:11 | <annevk> | Hixie: e.g. with potential CORS fetch it's pretty hard to figure out which requests will include an Origin header and which won't |
| 18:11 | <Hixie> | SteveF: sometimes the differences are that something i did doesn't get applied at all. |
| 18:11 | <slightlyoff> | TabAtkins: yes, today it is. |
| 18:11 | <TabAtkins> | slightlyoff: With one level of unwrapping, it works properly as a monad. With recursive unwrapping, it violates the monad contracts. |
| 18:11 | <annevk> | Hixie: it's hard to figure out if same-origin flag is the same as NO CORS, fail |
| 18:11 | <TabAtkins> | Which one you choose isn't a resolve-vs-accept choice, but rather an implementation detail of your resolve algorithm. |
| 18:12 | <annevk> | Hixie: it's hard to figure out if there are security bugs with data URLs when it comes to redirects (there are) |
| 18:12 | <Hixie> | annevk: not sure how changing the API would affect any of that. |
| 18:12 | <slightlyoff> | TabAtkins: I'm having a hard time caring about that. You and MarkM can fight it out. He believes the current design to be correct for reasons that require reading his thesis |
| 18:12 | <slightlyoff> | (which I have done and cant' actually summarize tersely for you here) |
| 18:12 | <SteveF> | Hixie: so if it was stated in the commit THIS IS DIFFERENT from WHATWG would that make it suffice? |
| 18:12 | <annevk> | Hixie: by not having the weird interwoven mix of sometimes invoking potential CORS and sometimes fetch but instead have one call site you can remove all that ambiguity |
| 18:12 | <Hixie> | SteveF: no, because that still wouldn't cover the cases of commits that just aren't applied. or things that are done differently, then later changed to match. |
| 18:12 | <slightlyoff> | TabAtkins: but do cc me on the discussion |
| 18:13 | <slightlyoff> | and annevk |
| 18:13 | <annevk> | Hixie: and actually reason about what kind of fetches are made |
| 18:13 | <slightlyoff> | ok, really going |
| 18:13 | <Hixie> | SteveF: the commit feed isn't useful for the purposes of someone just coming along and wanting to know in what ways the w3c changed the spec. |
| 18:13 | <TabAtkins> | slightlyoff: Once I figure out what both DOM Futures and Promises/A+ actually say, I'll do so. ^_^ |
| 18:13 | <Hixie> | annevk: well i don't mind if you just have "fetch" and "potentially cors-enabled fetch" just immediately invoke the same underlying algorithm, that'd be fine |
| 18:15 | <SteveF> | Hixie: OK will have to think upon it |
| 18:16 | <Hixie> | SteveF: (not does it give rationales) |
| 18:16 | <annevk> | Hixie: yes, there's something like that now, but I think long term the HTML specification ought to be fixed to make this far less hard to read |
| 18:17 | <annevk> | Hixie: that's the whole point of going through rationalising the platform's fetching algorithm |
| 18:17 | <Hixie> | SteveF: another way of putting it is, if someone looks at the two specs and finds a difference, where should they go to determine (a) if change was intentional and (b) why it was made, and then, (c) what other changes are made so they can determine (d) if any were not made that one would expect to have been made. |
| 18:18 | <Hixie> | annevk: i don't think the call sites are problematic. i agree the implementation of fetch was a disaster and crossed multiple specs back and forth and we should fix that (thanks for doing that), but i don't understand what you want to do to the call sites. |
| 18:19 | <Hixie> | annevk: maybe if you showed examples of call sites today and what you'd like them to look like instead that would help make your case. |
| 18:19 | <annevk> | Hixie: I suppose at some point I'll get to that |
| 18:20 | <annevk> | was hard enough figuring out what they were doing in the first place |
| 18:20 | <SteveF> | Hixie: OK I have endeavored to include pointers in my changes to bugs/wg discussions, what I would like to do is provide useful info but not do makework |
| 18:22 | <Hixie> | SteveF: i don't think it's reasonable to expect people to even know the bugs exist, and the mailing lists are extremely high-volume, so it doesn't help people work out what's different and why. |
| 18:23 | <Hixie> | SteveF: it's not make work, imho. |
| 18:23 | <Hixie> | SteveF: it would have helped catch some of the more serious mistakes that have been made so far. |
| 18:24 | <SteveF> | Hixie: that is why I add links to bugs and discussions in commits so people can read the history of the change |
| 18:25 | <Hixie> | again, people aren't going to know to look there |
| 18:25 | <SteveF> | Hixie: don't understand |
| 18:25 | <annevk> | SteveF: it's fairly common for downstream software projects to maintain a list of differences from upstream |
| 18:26 | <annevk> | SteveF: and kind of expected |
| 18:27 | <SteveF> | annevk: as i asked previously ted, silvia, robin et al were all editors before i started why are we having this discussion now? |
| 18:27 | <annevk> | SteveF: presumably because until now tracking has been not been considered too much work |
| 18:27 | <Hixie> | if some guy comes along and reads the specs, and wants to know why the w3c suggests that people who can see images shouldn't be told there's an audio captcha alternative, where should they go to find out? |
| 18:28 | <Hixie> | SteveF: i'm having this discussion now because you asked me a question |
| 18:28 | <Hixie> | SteveF: i'm happy to not have the discussion if you don't want to have it |
| 18:28 | <SteveF> | annevk: hixie: do you have any pointers to examples that could act as a guide to whats expected |
| 18:28 | <SteveF> | Hixie: I am perplexed as to why the question was never asked by others |
| 18:29 | <Hixie> | SteveF: well you'd have to ask them, not me |
| 18:29 | <SteveF> | i will |
| 18:29 | <Hixie> | SteveF: the way the whatwg spec listed differences back when i was doing this is an example of a low-maintenance way of doing it |
| 18:29 | <Hixie> | SteveF: (at the time, the w3c refused to publish the list in their copy for reasons i still don't understand) |
| 18:30 | <Hixie> | SteveF: i stopped maintaining the list when i lost track of what the differences were |
| 18:30 | <Hixie> | SteveF: which is why the whatwg doesn't have it anymore |
| 18:30 | <SteveF> | do you have apointer to a diff that shows what it was like, had a look but couldn't find when they were removed |
| 18:30 | <SteveF> | or a rough date? |
| 18:30 | <Hixie> | SteveF: (it's hard to maintain the list when you aren't the one making the changes) |
| 18:30 | <Hixie> | yeah hold on |
| 18:31 | <annevk> | SteveF: http://code.google.com/p/chromium-source-browsing/source/browse/README.chromium?repo=third-party--icu |
| 18:31 | <SteveF> | I have set up a wiki page and will record diffs there |
| 18:32 | <annevk> | (was fairly useful when figuring out what Chrome did with encodings) |
| 18:32 | <Hixie> | SteveF: we still have it here, for example: http://developers.whatwg.org/introduction.html |
| 18:32 | <Hixie> | under "How do the WHATWG and W3C specifications differ" |
| 18:32 | <SteveF> | hixie:annevk: thanks both useful |
| 18:32 | <Hixie> | SteveF: more detail would be great, but when i tried adding more detail i was told off for being "political" or some bs |
| 18:33 | <Hixie> | which is why the differences mentioned are sometimes a bit vague |
| 18:33 | <SteveF> | Hixie: i will try to provide detail |
| 18:33 | <Hixie> | the list anne mentioned is a good example of doing it in open source, yeah |
| 18:49 | <Hixie> | didn't we have a bug somewhere about making form submission a little more async? |
| 19:13 | annevk | doesn't remember that |
| 19:24 | <Hixie> | getComputedValue() returns the used values, right? |
| 19:24 | <Hixie> | or is there some value type between computed and used that i'm forgetting about |
| 19:25 | <Hixie> | specified is in the sheet, computed is inherited, used is what's used in layout, right? |
| 19:27 | <zcorpan> | Hixie: you mean getComputedStyle()? |
| 19:27 | <Hixie> | uh yeah |
| 19:27 | <webben> | Hixie: There are some edge cases where it's not really the used value |
| 19:27 | <zcorpan> | Hixie: it returns computed value for most properties, used value for a handful, iirc |
| 19:28 | <Hixie> | for 'top'? |
| 19:28 | <Hixie> | is this documented anywhere? |
| 19:28 | <zcorpan> | i thought it was in the spec at some point but the current spec just says "..." |
| 19:28 | <Hixie> | heh |
| 19:28 | <webben> | e.g. for example some browsers will tell you background-image is a url, even if they're not showing images |
| 19:29 | <webben> | I think Chrome does that |
| 19:29 | <annevk> | zcorpan: fuck that was removed???? |
| 19:29 | <zcorpan> | top is used value (unless the element is display:none) |
| 19:29 | <zcorpan> | https://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#widl-CSSStyleDeclaration-getPropertyValue-DOMString-DOMString-property |
| 19:29 | <Hixie> | webben: is the used value of 'background-image' set to none if the image isn't used? huh |
| 19:30 | <zcorpan> | i'll look into this |
| 19:30 | <webben> | Hixie: Chrome sets it to the unused image URL. |
| 19:30 | <Hixie> | zcorpan: https://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#resolved-value |
| 19:30 | <webben> | this is if you turn off images in chrome |
| 19:30 | <Hixie> | webben: that seems to match the spec |
| 19:31 | <zcorpan> | Hixie: ah |
| 19:32 | <annevk> | zcorpan: https://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#widl-Window-getComputedStyle-CSSStyleDeclaration-Element-elt seems defined still |
| 19:32 | annevk | spent a bunch of time on that; I would have been interested in reading why someone would have removed that |
| 19:33 | <webben> | Hixie: I guess that depends on how not using images is implemented |
| 19:33 | <webben> | but yeah if this happens outside the cascade entirely I guess that's true |
| 19:35 | <webben> | getActual would be kinda nice to have |
| 19:35 | <zcorpan> | i was looking at https://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#widl-CSSStyleDeclaration-getPropertyValue-DOMString-DOMString-property |
| 19:35 | <webben> | though i guess there would be security concerns with it leaking information about the user's system |
| 19:36 | <Hixie> | webben: hard to say what "actual" means sometimes |
| 19:37 | <Hixie> | e.g. if the image is being converted to black and white, the url wouldn't be the "actual value"... |
| 19:37 | <webben> | data uri? |
| 19:44 | <Hixie> | heh |
| 19:49 | <annevk> | https://chromiumcodereview.appspot.com/14273007/ ouch |
| 19:52 | <Hixie> | ouch because ew, more accept headers? |
| 19:55 | <jgraham> | Not just "ough Rietveld"? :p |
| 19:55 | <jgraham> | *ouch |
| 19:55 | <jgraham> | In related news, is today international "push more changes to closed pull requests" day or something? |
| 19:56 | <SteveF> | Hixie: "if some guy comes along and reads the specs, and wants to know why the w3c suggests that people who can see images shouldn't be told there's an audio captcha alternative, where should they go to find out?" don't understand this, the spec does not say don't tell people |
| 20:00 | <annevk> | Hixie: uhuh |
| 20:23 | <Hixie> | SteveF: the example of a captcha in the w3c version only mentions the audio version if you don't see the image, whereas the example in the whatwg spec tells everyone about it. |
| 20:23 | <Hixie> | SteveF: this is exactly the kind of difference where documentation would help determine if the difference is just a mistake or intentional |
| 20:24 | <SteveF> | Hixie: OK |
| 23:02 | <jsbell> | Any Moz IDB folks around? |
| 23:04 | <jsbell> | Ah, sicking: IDB question for you: s = db.createObjectStore('s'); db.deleteObjectStore('s'); s.get(0); --> should throw InvalidStateError, per spec blather about operation on deleted object? FF20 appears not to. Bug or am I missing something? |
| 23:12 | <sicking> | jsbell: hey |
| 23:21 | <sicking> | jsbell: i think you broke the spec :) |
| 23:23 | <jsbell> | sicking: hrm... left something out in my removal of exception tables, or something more fundamental? |
| 23:23 | <sicking> | jsbell: Throwing a InvalidStateError sounds correct. I don't know what you mean by "spec blather"? :) |
| 23:23 | <sicking> | jsbell: the TOC is completely busted |
| 23:23 | <jsbell> | Huh.... |
| 23:23 | <sicking> | jsbell: i see a lot of 0's everywhere |
| 23:23 | <jsbell> | Odd. Looks fine to me... |
| 23:24 | <sicking> | ble of Contents |
| 23:24 | <sicking> | 0 |
| 23:24 | <sicking> | 1. 00Introduction000 |
| 23:24 | <sicking> | 0 |
| 23:24 | <sicking> | 2. 00Conformance000 |
| 23:24 | <sicking> | 2.1 00Dependencies000 |
| 23:24 | <sicking> | 00 |
| 23:24 | <jsbell> | trying ff.... |
| 23:24 | <jsbell> | looks fine to me in FF20 as well. |
| 23:24 | <jsbell> | https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html ? |
| 23:24 | <sicking> | woha, looks fine in chrome |
| 23:25 | <sicking> | ooh, and fine in FF20 too |
| 23:25 | <jsbell> | perhaps you broke firefox? :) |
| 23:25 | <sicking> | i think i did :) |
| 23:25 | <jsbell> | ignore "blather". I just meant the boilerplate on each method about throwing when the object is deleted |
| 23:26 | <sicking> | crazy, i rarely see such bad bustage on nightlies |
| 23:26 | <sicking> | dbaron: hey |
| 23:26 | <dbaron> | sicking, hi |
| 23:26 | <sicking> | dbaron: i going to blame your team for this :) |
| 23:26 | <dbaron> | sicking, what? |
| 23:27 | <sicking> | oh, man, it's in the DOM, i can't blame you |
| 23:27 | <sicking> | dbaron: spec bustage in nightlies |
| 23:27 | <dbaron> | sicking, I think there was some js stuff backed out, and nightlies respun |
| 23:27 | <dbaron> | sicking, but yes, builds were pretty busted earlier |
| 23:28 | <jsbell> | sicking: If you file a FF bug about throwing InvalidStateError, also consider the transitive cases (index of deleted store, cursors of deleted index/store). I just noticed we get those cases wrong in Chrome. |
| 23:28 | <sicking> | jsbell: will do |
| 23:29 | <sicking> | jsbell: are you working on defining exception ordering? |
| 23:30 | <jsbell> | sicking: no, per the spec bug I just got rid of the exception tables, didn't impose an ordering. but while doing so, had a nagging feeling about those edge cases |
| 23:30 | <sicking> | jsbell: ah, i see |
| 23:31 | <sicking> | jsbell: are you coming on wednesday morning btw? With EricU? |
| 23:31 | <jsbell> | sicking: yes! |
| 23:32 | <sicking> | jsbell: sweet! I want to talk about temporary vs. permanent databases |
| 23:32 | <jsbell> | sgtm |
| 23:39 | <Hixie> | MikeSmith: do you know if the bugzilla w3c uses supports the "needsinfo" fields? |
| 23:40 | <sicking> | jsbell: do you know if you guys have any additions to the current spec that you'd like to see sooner rather than later? |
| 23:43 | <jsbell> | sicking: the low hanging fruit are continuePrimaryKey() and objectStore.openKeyCursor(); beyond that are things we need to experiment with first like indexeddb:// URLs, database observers, binary data keys, DOM Futures-based API, expression-based indexing... |
| 23:44 | <jsbell> | Apparently the TC39/I18n crew is proposing a text segmentation API which would help with full-text search if combined with expression indexing. |
| 23:45 | <sicking> | jsbell: nice. I'd add index.openCursor which allows specifying a primary key too |
| 23:45 | <sicking> | i am very curious how we'd do indexeddb: URLs. Seems tricky unless you restrict what types of things you could access through it |
| 23:46 | <jsbell> | Given that Chrome doesn't support blobs-in-idb yet it's too early for us to even experiment. |
| 23:46 | <sicking> | ah, true |
| 23:46 | <sicking> | oh, i was curious if that's easier for you guys to implement now that you've forked webkit |
| 23:46 | <jsbell> | The canonical example is album art for your IDB of music metadata. |
| 23:47 | <sicking> | sounded like one of the bug advantages was that you can simplify the process separation stuff |
| 23:47 | <sicking> | s/bug/big/ |
| 23:47 | <jsbell> | sicking: yes; we're refactoring to pull code out of blink into chromium now to remove a couple of layers of indirection |
| 23:47 | <jsbell> | and blob support is something that'll get much easier |
| 23:48 | <sicking> | nice! |
| 23:50 | <sicking> | hmm.. i wonder if something as simple as indexeddb:http://foo.com/dbname/objectstore/key would be enough |
| 23:50 | <sicking> | it wouldn't let you address blobs inside of structured clones |
| 23:51 | <sicking> | and it's tricky if the key is something other than a string |
| 23:51 | <sicking> | but if you're willing to live with those limitations, it'd work |
| 23:52 | <sicking> | you could even allow "indexeddb:http://foo.com/dbname/objectstore/foo/bar/baz.html"; if "foo/bar/baz.html" was the key |
| 23:53 | <jsbell> | index gets would be nice |
| 23:54 | <jsbell> | as would #key.path to pull out fragments of an object |
| 23:54 | <sicking> | hmm.. good point |
| 23:54 | <jsbell> | but yeah, we need to ponder a bit |
| 23:54 | <sicking> | i think the keypath would have to be part of the url, not part of the fragment |
| 23:54 | <jsbell> | and it should use the current version, but not trigger an upgrade to v1, etc etc. |
| 23:54 | <sicking> | so that you can use fragments to identify things within a blob |
| 23:54 | <jsbell> | Ah, good point |
| 23:56 | <sicking> | yeah.. this stuff gets messy :( |
| 23:56 | <sicking> | it would be very cool though |