| 01:52 | <othermaciej> | Hixie: do you know offhand which Web Apps WG specs were factored out of WHATWG's HTML spec? |
| 02:02 | <Hixie> | othermaciej: should be a list of them in the whatwg faq, but i can never recall the exact list |
| 02:03 | <othermaciej> | Hixie: is your "should be" meant to say "is" or "ought to be but is not" |
| 02:03 | <othermaciej> | or that you are uncertain? |
| 02:03 | <othermaciej> | ah, I found the list |
| 02:09 | <Hixie> | othermaciej: ought to, not sure if it's up to date |
| 06:10 | <annevk> | some stuff migrated back recently |
| 06:11 | <othermaciej> | what stuff? |
| 06:44 | <annevk> | othermaciej: http://www.whatwg.org/specs/ |
| 06:46 | <othermaciej> | neat to see those things, I was specifically wondering about factored out pieces of the WHATWG's "HTML Living Standard" spec, and it seems like the things on that page are separate items |
| 06:46 | <othermaciej> | or are they intended to be folded into HTML LS? |
| 06:47 | <annevk> | ah no |
| 06:48 | <annevk> | it's just that XHR once was split out and moved to the W3C and now it's back |
| 06:48 | <annevk> | but yeah, not in the same place |
| 06:48 | <othermaciej> | was XHR once one of the big monolithic thing formerly known as Web Apps 1.0? |
| 06:49 | <annevk> | yeah |
| 06:49 | <othermaciej> | I'd forgotten that |
| 06:49 | <othermaciej> | do you remember when it got split? |
| 06:49 | <annevk> | 2006 |
| 06:50 | <othermaciej> | thanks |
| 07:51 | smaug____ | wonders which ancient bugzilla version w3 uses |
| 07:53 | <jgraham> | Bugzilla 3.6.2 |
| 07:54 | <annevk> | why are Safari's password dialogs synchronous? |
| 07:54 | <annevk> | so annoying |
| 07:55 | <jgraham> | You mean modal? |
| 07:55 | <annevk> | I suppose |
| 07:59 | <zcorpan> | deane: http://www.whatwg.org/specs/web-apps/current-work/multipage/iana.html#text/html |
| 08:05 | <[tm]> | if John Daggett comes back around, please ask him to re-ping me |
| 08:05 | <[tm]> | aka nattokirai |
| 08:05 | <[tm]> | I'm in Budapest and don't have IRC access from my PC |
| 08:19 | <zcorpan> | Hixie: the quirks mode spec is part of WHATCG. should it be listed under specs/ as well? |
| 08:28 | <annevk> | DOM Parsing should maybe be listed too |
| 08:28 | <annevk> | zcorpan: you want to put it on github and get quirks.spec.whatwg.org ? |
| 08:28 | <zcorpan> | Hixie: so we don't want to support dropping directories at all because it's a can of worms of security problems and various complexities |
| 08:29 | <zcorpan> | annevk: maybe, yeah. what's the procedure assuming i want to keep the CLA in sync? |
| 08:31 | <annevk> | dunno, I guess then you'd have to push to both |
| 08:31 | <zcorpan> | do you only maintain the *.spec.whatwg.org specs now? |
| 08:31 | <annevk> | yup |
| 08:31 | <zcorpan> | ok |
| 08:32 | <annevk> | I can't join the W3C as I don't agree with the Agreement |
| 08:32 | <annevk> | but I still like editing |
| 08:32 | <zcorpan> | right |
| 08:33 | <zcorpan> | you should have a license for your specs such that forking is allowed but only for a fee going straight to your pocket :-) |
| 08:33 | <odinho> | If the forking entity is a big standards organization that starts with W and ends with 3C. |
| 08:33 | <annevk> | I was actually thinking of something like that, to get some money, but I didn't really like that model |
| 08:34 | <annevk> | I'll stick to Public Domain and find some other source of income in due course |
| 08:34 | <zcorpan> | so what's your business plan? |
| 08:34 | <zcorpan> | ok |
| 08:34 | <zcorpan> | flipping burgers? |
| 08:34 | <annevk> | vacation :) |
| 08:35 | <SimonSapin> | annevk: what part of the Agreement don’t you agree with? |
| 08:35 | <annevk> | the part that basically gives the W3C exclusive right to my creative work |
| 08:35 | <smaug____> | oh, hmm, need to get AryehGregor and Ms2ger (where is he btw) actively merge Anne's whatwg DOM to W3 DOM |
| 08:35 | <annevk> | smaug____: vacation |
| 08:38 | <smaug____> | oh, vacation |
| 08:38 | <smaug____> | odd |
| 08:38 | <smaug____> | that is at least 2nd time this year |
| 08:38 | <smaug____> | he is getting old |
| 08:40 | <smaug____> | annevk: so do you have a list of non-w3c specs you're editing now? |
| 08:40 | <annevk> | smaug____: whatwg.org/specs |
| 08:42 | <smaug____> | annevk: have you discussed with Art or perhaps AryehGregor/Ms2ger how to coordinate spec editing |
| 08:42 | <annevk> | just Ms2ger |
| 08:42 | <smaug____> | and what did he say? |
| 08:42 | <annevk> | talked with Art too |
| 08:43 | <annevk> | smaug____: nothing much |
| 08:43 | smaug____ | would like to just know which spec to follow |
| 08:43 | <annevk> | smaug____: this setup works for him too |
| 09:04 | <jgraham> | So, does anyone know what the rules are for sharing resources in a document? |
| 09:05 | <jgraham> | e.g. if I have <img src=a><img src=a><img src=a> it seems like a should be loaded only once |
| 09:05 | <jgraham> | but <script src=a></script><script src=a></script><script src=a></script> might be 3 loads? |
| 09:08 | <annevk> | they can all be shared |
| 09:11 | <annevk> | jgraham: fetch describes those "rules" fwiw |
| 09:16 | <jgraham> | annevk: Apparently (and I quote) "we know that scripts aren't shared" |
| 09:17 | <jgraham> | I haven't done the experiment, but if I trust bratell it seems like the rules are more complicated than "share everything" |
| 09:17 | <annevk> | jgraham: you mean they always force a new HTTP request somehow? |
| 09:17 | <jgraham> | Well I don't know about "always" |
| 09:17 | <jgraham> | But at least in some circumstances, yes |
| 09:19 | <jgraham> | (speculative theories included "cache until the load event", "never cache scripts", "only cache images" and "only cache resources that are referenced by an element currently in the document") |
| 09:20 | <jgraham> | But since this is observable with e.g. cookies (not to mention race conditions), it is a compat issue |
| 09:21 | <annevk> | well of course |
| 09:22 | <annevk> | sounds like fetch needs another flag |
| 09:22 | <annevk> | unless scripts is already special cased |
| 09:54 | <annevk> | Hixie: I think I fixed the Referer stuff now, review would be appreciated |
| 09:55 | <annevk> | sicking: ^^ |
| 10:55 | <smaug____> | hmm, when did workers lose close event |
| 11:00 | <zcorpan> | close event? |
| 11:05 | <zcorpan> | sometime between http://www.w3.org/TR/2009/WD-workers-20090423/ and http://www.w3.org/TR/2009/WD-workers-20091029/ |
| 11:10 | <zcorpan> | smaug____: http://lists.w3.org/Archives/Public/public-whatwg-archive/2009May/0406.html |
| 11:10 | <smaug____> | I wonder how many implementations still have it |
| 11:10 | <smaug____> | at least one |
| 11:11 | smaug____ | hasn't really followed all the worker discussions |
| 11:11 | <smaug____> | at least not at that time |
| 11:11 | <smaug____> | zcorpan: thanks! |
| 11:12 | <zcorpan> | http://html5.org/r/3143 |
| 11:12 | <zcorpan> | opera doesn't have it |
| 11:12 | <zcorpan> | i think it was removed before we started implementing |
| 11:14 | <zcorpan> | what's the status for shared workers in gecko? |
| 11:24 | <smaug____> | zcorpan: I guess someone is starting to implement them |
| 11:26 | <zcorpan> | ok |
| 11:56 | <cheron> | Why is there no possibility to communicate between all open tabs of my domain in HTML5? |
| 11:56 | <annevk> | you can via localStorage I think |
| 11:58 | <cheron> | annevk: yes, badoo.com does it like this, but there are no efforts to provide a seperate API for that? |
| 11:58 | <annevk> | come to think of it, I guess SharedWorker allows for it too |
| 11:59 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689#c27 spam? |
| 12:01 | <cheron> | so there is no need for an explicit api? |
| 12:03 | <darobin> | I have a dim memory of using postMessage for that, but I'm not sure it ever became true |
| 12:03 | <annevk> | cheron: depends on whether there are a) use cases and b) nothing to address a |
| 12:04 | <darobin> | I recall one of the use cases being on YouTube having only the tab with page visibility play the music, and automatically tell the others to mute |
| 12:10 | <annevk> | zcorpan: http://xhr.spec.whatwg.org/#same-origin-request-steps and scroll up a notch; that makes data URLs work the way you want right? |
| 12:10 | <annevk> | zcorpan: do you remember if there was a thread or bug report for that? |
| 12:10 | <annevk> | darobin: you can do that via sharedWorkers and localStorage |
| 12:11 | <annevk> | (I think) |
| 12:11 | <darobin> | annevk: yeah, as far as I know that's how most people do it — it's not something I've had a reason to try so far |
| 12:35 | <annevk> | hsivonen: http://wiki.whatwg.org/wiki/Talk:Main_Page third box might be for you? |
| 12:36 | <zcorpan> | annevk: how does that deal with redirects to not-same-origin? |
| 12:36 | <annevk> | zcorpan: this is before redirects |
| 12:37 | <annevk> | zcorpan: I attempted to support it the same way as is done for workers |
| 12:38 | <annevk> | zcorpan: by checking the moment you supply the URL, rather than checking throughout the request |
| 12:38 | <annevk> | (well not actually when you supply the URL, but close to it) |
| 12:38 | <zcorpan> | workers don't support cross-origin at all, right? |
| 12:38 | <annevk> | right |
| 12:39 | <annevk> | but data URLs go together with the initial same origin check |
| 12:39 | <annevk> | so if it's same-origin and then a redirect to a data URL, it will fail |
| 12:39 | <zcorpan> | <img> and <track> support first requesting a same-origin url and then redirecting to a not-same-origin url and have it switch to the cross-origin branch |
| 12:40 | <zcorpan> | hmm, i haven't thought much about redirects to data: |
| 12:40 | <annevk> | well sure, XHR does too |
| 12:40 | <annevk> | but that has nothing to do with data URL support |
| 12:41 | <annevk> | are you not commenting on the data URL part? |
| 12:43 | <zcorpan> | right, sorry, i was commenting about non-data-URL same-origin redirecting to not-same-origin |
| 12:45 | <zcorpan> | does "and the rules listed at the end of this section." take care of that? |
| 12:46 | <annevk> | http://xhr.spec.whatwg.org/#same-origin-request-event-rules does |
| 12:46 | <annevk> | just updated to take 308 into account |
| 12:47 | <zcorpan> | ah, ok |
| 12:48 | <zcorpan> | then it's good, assuming it doesn't have the same bugs i reported on "potentially cors-enabled fetch" in html :-) |
| 12:50 | <annevk> | would have to read those bugs to be sure |
| 12:50 | <annevk> | but if this still has major holes, I'd worry about user security |
| 12:50 | <zcorpan> | what do browsers do when redirecting to data: ? |
| 12:51 | <annevk> | I don't think all browsers support data: to begin with |
| 12:51 | <annevk> | you know what's an interesting edge case |
| 12:51 | <annevk> | a redirect to a blob URL |
| 12:54 | <zcorpan> | yeah. i hope that shouldn't work :-) |
| 12:58 | <annevk> | I think it should given the current definitions |
| 12:58 | <annevk> | unless maybe its oneTimeOnly or whatever it's called flag is set |
| 13:00 | <darobin> | there's no reason a redirect to a blob uri shouldn't work |
| 13:01 | <darobin> | though how useful exactly that's another question :) |
| 13:30 | <annevk> | anyone familiar with the domain-related code of URLs? |
| 13:30 | <annevk> | in particular what I'm wondering about is how much happens during parsing |
| 13:31 | <annevk> | and when (and if) invalid characters turn the URL invalid |
| 13:49 | <annevk> | TIL domain names use NFKC |
| 13:51 | <jgraham> | I hope you found the heritic and pushed them off a bridge |
| 13:53 | <annevk> | good memory! |
| 13:53 | <annevk> | http://code.google.com/p/plainrss/source/browse/trunk/Atom.NET/tests/feeds/pilgrim.xml |
| 13:54 | <annevk> | I wonder if he was looking at domain names too at the time |
| 13:56 | <annevk> | but I guess I should just say "this is how you find the host name, now apply ToASCII to it" |
| 14:01 | <annevk> | implementing IDNA ToASCII in JavaScript might be a bridge too far |
| 14:46 | <annevk> | setting .protocol is highly illogical |
| 14:46 | <annevk> | e.g. you have http://test/ |
| 14:46 | <annevk> | now you set protocol to https |
| 14:46 | <annevk> | my URL library makes that https://test:80/ |
| 14:46 | <annevk> | most browsers have https://test/ |
| 14:47 | <annevk> | completely ignoring that they now also changed the port |
| 14:47 | <jgraham> | But I would totally expect the browser behaviour to work and yours to break |
| 14:47 | <annevk> | or if you change away from https the // is kept |
| 14:48 | <annevk> | but if you change from data to https, the // is added |
| 14:48 | <jgraham> | I mean if you have a specified port then it should be constant, but if you are using the default it should be the default on the new scheme too, I guess |
| 14:52 | <annevk> | it seems Chrome just sets port to the empty string if you give it the default port |
| 14:52 | <annevk> | that certainly explains the serialization |
| 14:53 | <annevk> | Gecko does the same |
| 14:53 | <annevk> | HTML of course does not define this |
| 14:53 | <annevk> | well "of course" |
| 14:53 | <annevk> | sorry Hixie but the URL decomposition attributes are poorly done |
| 14:55 | <smaug____> | Hmm, webidl parser claims that void observe(Node target, MutationObserverInit options); isn't right |
| 14:55 | <smaug____> | that the latter parameter should be optional |
| 14:56 | <annevk> | you don't have to mark it optional for it to be optional I think |
| 14:56 | <annevk> | heycam|away: ? |
| 15:01 | <Hixie> | zcorpan: happy to add anything you want to the specs list |
| 15:03 | <Hixie> | jgraham: <img> is especially magical regarding duplicate resource loads; beyond that there's just HTTP caching and coalescing of multiple simultaneous requests. If there's a compat reason not to coalesce, file a bug. |
| 15:03 | <Hixie> | annevk: link to xhr/cors updates? |
| 15:04 | <jgraham> | Hixie: "especially magical" doesn't sound terribly well defined. Nor does "coalescing of multiple simultaneous requests", really |
| 15:05 | <Hixie> | annevk: url decomposition is a bit of a mess, but is it normatively ok? |
| 15:05 | <annevk> | Hixie: https://github.com/whatwg/xhr/commit/69f790f185aaf611a138742362dda55c1a3f7da7 and https://github.com/whatwg/fetch/commit/8d8fbd9e36b725e11afd679c9c0d8fe8ffced8bd |
| 15:05 | <Hixie> | jgraham: they're both quite well defined |
| 15:05 | <Hixie> | jgraham: insofar as they can be. <img> in particular. |
| 15:06 | <annevk> | Hixie: no, e.g. setting .port to 80 for "http://test/"; should make it the empty string |
| 15:06 | <Hixie> | annevk: file bugs |
| 15:06 | <jgraham> | Hixie: In HTML? |
| 15:07 | <annevk> | Hixie: my plan is to obsolete you in the next few months |
| 15:07 | <Hixie> | jgraham: yes |
| 15:07 | <Hixie> | annevk: that wfm |
| 15:07 | <annevk> | Hixie: maybe that's optimistic, but in due course |
| 15:08 | <jgraham> | Hixie: Interesting |
| 15:08 | <Hixie> | annevk: xhr doesn't look like it has a <dfn> for XMLHttpRequest referrer source in that diff |
| 15:09 | <Hixie> | annevk: otherwise seems ok, i'll have to update my cors calls |
| 15:09 | <annevk> | Hixie: ah sorry, https://github.com/whatwg/xhr/commit/91670112d639e3f5f1899efd188d9e0425963036 |
| 15:09 | <annevk> | made two changes to XHR |
| 15:10 | <Hixie> | lgtm |
| 15:13 | <Hixie> | ok updated html |
| 15:20 | <annevk> | Hixie: at some point you should prolly update the reference section to point to xhr.spec.whatwg.org etc. |
| 15:20 | <Hixie> | file a bug |
| 15:23 | <annevk> | fair enough |
| 15:31 | <Hixie> | darobin: while merging the last few checkins you've made, i've ended up using different prose (for different reasons each time; i tried to document them in detail in the checkin comments). Is this something silvia will end up tracking automatically or should I be bringing this up to someone's attention or is it something where we don't care? |
| 15:32 | <darobin> | Hixie: I think that ideally the prose should be the same unless there's an overwhelming reason not to do so |
| 15:33 | <darobin> | normally I think Silvia will track it (or whoever looks at deltas later), but pointers to the differences are appreciated (especially if they can avoid further difference in future) |
| 15:34 | <Hixie> | k |
| 15:35 | <Hixie> | darobin: r7344, r7337, r7336, and r7334 are the main ones that map to things you've changed recently, i think |
| 15:35 | <Hixie> | darobin: (i've been trying to make sure i fix the bugs you fix around the same time) |
| 15:39 | <darobin> | Hixie: heh, for r7344 you have the exact text I had before I decided I preferred reordering the list differently :) |
| 15:40 | <Hixie> | heh |
| 15:40 | <Hixie> | your current text reads like getting and setting always throws, and methods throw when they don't apply |
| 15:41 | <Hixie> | (and starts with "On" while the next paragraph uses "For", which reads weird) |
| 15:41 | <darobin> | we don't parse commas in the same way :) |
| 15:41 | <darobin> | but noted |
| 15:42 | <Hixie> | the problem isn't whether you or i parse commas in the same way, it's how will a hostile reader read it :-) |
| 15:42 | <Hixie> | that's why the paragraph was being rewritten in the first place, after all :-) |
| 15:42 | <darobin> | sure, it just looks like my hostile reader came from Oxford |
| 15:42 | <darobin> | that would explain the smell of tweed on my right shoulder |
| 15:43 | <darobin> | thanks for the heads up, I won't copy those change directly but will rather cherry pick them downstream |
| 15:44 | <Hixie> | (oh, also r7331) |
| 15:44 | <Hixie> | k |
| 15:48 | <darobin> | Hixie: oh yeah, I need to return to that oen |
| 15:48 | <darobin> | it raises a red flag for me that the new supposedly better constructor would require a helper function in simple spec example code |
| 15:49 | <darobin> | which is why I assumed the original example must have been wrong :) |
| 15:49 | <Hixie> | there's a reason i had originally designed it the way i had... |
| 15:49 | <Hixie> | :-P |
| 15:49 | <darobin> | heh |
| 15:50 | <Hixie> | depends what the most common use case is going to be: adding subtitles, or adding metadata |
| 15:50 | <darobin> | I can't disagree that having too many positional parameters is painful though |
| 15:50 | <darobin> | this strikes me as a case for a dictionary... |
| 15:51 | <darobin> | I'll scare up a proposal in the bug |
| 15:51 | <darobin> | (which was REOP) |
| 16:05 | <Hixie> | darobin: i dunno that a dictionary makes much sense here. all the values are mutable now, and if the common case is subtitles, you'll rarely need to change them anyway. |
| 16:07 | <Hixie> | darobin: (fwiw, i usually try to have the examples in the spec show both the easy ways to use the APIs and the more esoteric ways, so making the API support the examples in the spec specifically is probably not a winning strategy :-) ) |
| 16:07 | <darobin> | yeah, I was just wondering whether the various uses would justify a dictionary, versus changing the example to use subtitles |
| 16:07 | <Hixie> | we can certainly add more examples |
| 16:08 | <Hixie> | but that's a different issue entirely |
| 16:08 | <darobin> | yeah, I'm definitely not trying to design against the example, but I think it makes sense to exemplify the common case |
| 16:08 | <darobin> | I know that's the first thing I look at when coding |
| 16:11 | <annevk> | heh fun |
| 16:11 | <annevk> | Gecko's URL thing is quite broken |
| 16:11 | <annevk> | if you set hostname to "x#" |
| 16:11 | <annevk> | well host |
| 16:12 | <annevk> | you get http://x/#/ |
| 16:12 | <annevk> | or if you set it to "\n" it puts part of the path as the host |
| 16:12 | <odinho_> | Heh, good thing people don't do that then :] |
| 16:13 | <Hixie> | i love how the url parsing stuff is so complicated that each time someone tries to spec it, they learn more quirks than the previous person |
| 16:14 | <Hixie> | and then the next person comes along, sees all the quirks so far, tests all of those again, then tests a few more things, finds more quirks, and lather rinse repeat |
| 16:14 | <annevk> | for something fundamental to the platform, it's quite complicated |
| 16:15 | <annevk> | my library is now 350 lines (also handles the decomposition attributes) |
| 16:15 | <annevk> | once it's a bit more polished I'll put it online for review and then turn it into a proper spec |
| 16:17 | <odinho> | annevk: With a small eye towards some potential simplification I hope? :P |
| 16:22 | <annevk> | single-pass parsing was my goal |
| 16:23 | <annevk> | some stuff is simplified too I think |
| 16:23 | <annevk> | because they're no longer constrained by silly syntax constructs from the IETF |
| 16:23 | <annevk> | hmm |
| 16:24 | <annevk> | just realized that apart from the IDNA ToASCII thing, there's also figuring out whether it's a host or IP address |
| 16:24 | <annevk> | browsers do weird things with normalizing IP addresses too I noticed |
| 16:43 | <tantek> | good morning #whatwg. perhaps a bit of a reach, but any others here in Portland this weekend for XOXO festival? |
| 17:06 | <annevk> | oh heh |
| 17:06 | <annevk> | IP address syntax notation has a versioning strategy |
| 17:07 | <annevk> | hopefully that's never going to be used |
| 17:08 | <zcorpan> | annevk: what? for ipv7? |
| 17:08 | <annevk> | read and weep http://tools.ietf.org/html/rfc3986#section-3.2.2 |
| 17:09 | <Hixie> | wow, that's hard core |
| 17:18 | <zcorpan> | annevk: do browsers support the versioning syntax? |
| 17:19 | <zcorpan> | oh i see they aren't expected to |
| 17:21 | <zcorpan> | well then it doesn't need to be specced, it can wait until ipv7 comes along and see if it needs a flag |
| 17:24 | <zcorpan> | Hixie: ok. can you add it? :-) url is http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.html |
| 17:25 | <Hixie> | i'm running out the door, drop me a mail? |
| 17:25 | <Hixie> | sorry |
| 17:26 | <zcorpan> | sure |
| 17:56 | <Famic> | hi |
| 18:14 | <zcorpan> | Famic: hi |
| 19:06 | <Hixie> | sicking: we think we fixed your referrer issue |
| 19:07 | <Hixie> | sicking: re dnd of directories, opera (zcorpan, i think) says they don't want to support directories at all. you said mozilla does want to do directories, right? in addition to handling thousands of files in one directory? |
| 19:08 | <zcorpan> | here's why opera doesn't want to support it (longish paste, sorry): |
| 19:08 | <zcorpan> | What happens when the directory structure has a loop? on unix you can have hard links that are undetectable, and can create infinite loops of various kinds. |
| 19:08 | <zcorpan> | |
| 19:08 | <zcorpan> | What happens when the user drops / (root directory) or c:\ ? |
| 19:08 | <zcorpan> | |
| 19:09 | <zcorpan> | What happens when the directories contain ".." links to the parent - what permission was granted (eg. read the parent folder contents)? |
| 19:09 | <zcorpan> | |
| 19:09 | <zcorpan> | What should happen with path names if the user drops /home/ or c:\users\ - should the Web site be given a directory structure which then exposes the usernames and profile paths (which the user would *never* want to expose, but wouldn't realise they are exposing)? |
| 19:09 | <zcorpan> | |
| 19:09 | <zcorpan> | What happens if two folders contain the same file name (assuming that you expose just the files instead of letting the script browse folder structure)? |
| 19:09 | <zcorpan> | |
| 19:09 | <zcorpan> | This is hell, and I just don't want to go there. |
| 19:09 | <zcorpan> | (gotta go) |
| 21:05 | <sicking> | Hixie: yes, we want to do directories with thousands of files in them |
| 21:06 | <Hixie> | sicking: i mean, you want to expose a hierarchy, in addition to supporting the user dragging a ton of files flat |
| 21:07 | <sicking> | Hixie: yes, i want to expose the heirarcy, but it doesn't have to be throught the ability to traverse a directory tree. Though it's an advantage if that can be done as well, though much lower priority |
| 21:07 | <sicking> | Hixie: i.e. exposing a list of files with names like "foo/bar/baz.doc" is enough to expose hierarchy |
| 21:08 | <Hixie> | by "hierarchy", i mean specifically not giving everything in one flat synchronous list |
| 21:13 | <sicking> | well |
| 21:13 | <sicking> | a flat list could be ok |
| 21:14 | <sicking> | as long as we can provide some sort of useful progress events as we are "loading" that list (which is hard since we can't give a percentage since we don't know how many files total) |
| 21:15 | <sicking> | oh, but i guess that if you mean "synchronous" you mean synchronously from the "drop" event, then that's not good, yes |
| 21:17 | <jgraham> | What are your solutions for the security/privacy issues that zcorpan mentioned? |
| 21:17 | <Hixie> | i have no solution |
| 21:17 | <Hixie> | fwiw |
| 21:18 | <sicking> | neither do I |
| 21:18 | <jgraham> | That seems like a problem :( |
| 21:18 | <Hixie> | problems, that i have |
| 21:18 | <sicking> | but i don't know what the security/privacy issue that zcorpan mentioned is |
| 21:19 | <jgraham> | sicking: You just assume you don't have a solution to any security / privacy issues? :) |
| 21:19 | <Hixie> | jgraham: it's a pretty good starting assumption :-) |
| 21:19 | <jgraham> | sicking: http://krijnhoetmer.nl/irc-logs/whatwg/20120913#l-1154 |
| 21:19 | <sicking> | "<sicking> *neither* do I" (emphasis added by me) |
| 21:20 | <sicking> | oh |
| 21:20 | <sicking> | you said "don't" :) |
| 21:21 | <sicking> | jgraham: good questions indeed |
| 21:21 | <Hixie> | the loop one is particularly bad and pretty much means we can't do a flattening solution |
| 21:21 | <Hixie> | but that's really just pushing the problem into the script |
| 21:21 | <jgraham> | Yeah, I should find out who came up with the list :) |
| 21:22 | <sicking> | jgraham: i'd be inclined to simply not follow links |
| 21:22 | <sicking> | jgraham: seems like that would still retain the majority of use cases |
| 21:22 | <jgraham> | sicking: Does that work for hard links? |
| 21:23 | <sicking> | jgraham: you keep having all these good questions :) |
| 21:25 | <Hixie> | you can't not follow links |
| 21:25 | <Hixie> | they're indistingushable from directories :-) |
| 21:26 | <jgraham> | I think I ought to sleep now |
| 21:39 | <Hixie> | sicking: can you elaborate on why you don't want to use the filesystem api for this? do you just not think we should have that api at all? |
| 22:09 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689#c27 o-O |
| 22:10 | <Hixie> | darobin: you're fixing appcache? |
| 22:11 | <darobin> | Hixie: the discussion is open, no decision has been made yet |
| 22:12 | <darobin> | right now I'm mostly listening to the Fixing AppCache people |
| 22:13 | <Hixie> | there are Fixing AppCache people? |
| 22:13 | <darobin> | yeah there were two meetings, one in London, another in Mountain View with several implementers and die-hard users of appcache |
| 22:14 | <Hixie> | ah yes, i have heard of those |
| 22:14 | <Hixie> | none of the feedback from those meetings seems to ever make it to the bug database |
| 22:14 | <darobin> | by that I mean folks like Facebook, Pearson, Web Outlook, etc. |
| 22:14 | <Hixie> | at least not in actionable form (use cases) |
| 22:15 | <darobin> | no, the design is too much up in the air for that at this point |
| 22:15 | <Hixie> | what i have heard is mostly going to result in incremental changes, though, so i doubt it'll affect https://www.w3.org/Bugs/Public/show_bug.cgi?id=18272 |
| 22:15 | <Hixie> | or https://www.w3.org/Bugs/Public/show_bug.cgi?id=18280 |
| 22:15 | <darobin> | maybe, maybe not |
| 22:16 | <Hixie> | pretty sure not :-) |
| 22:16 | <darobin> | I've heard both |
| 22:16 | <darobin> | I'm essentially moving those bugs to the later bucket until I hear something more concrete |
| 22:17 | <Hixie> | http://goo.gl/VrQNF is the concrete list of what is going to change |
| 22:17 | <darobin> | if it turns out to be incremental, I can look at them then, if not, then I'll be glad I didn't dig any deeper |
| 22:19 | <darobin> | Hixie: last I heard there was still disagreement between implementers, so I just want to make sure all the Ts are crossed |
| 22:20 | <Hixie> | if they don't participate in the discussions, their disagreements aren't going to have much effect on the spec :-) |
| 22:21 | <darobin> | I think they plan to :) |
| 22:21 | <darobin> | anyway, it's bedtime in this TZ :) nn! |
| 22:22 | <othermaciej> | Hixie, darobin: is there any written down and publicly viewable form of all this feedback? |
| 22:23 | <othermaciej> | as an implementor of AppCache that I think has not been party to these discussions, I am interested |
| 22:23 | <othermaciej> | darobin: you should really move deferred bugs to another component instead of RESOLVED LATER btw |
| 22:58 | <smaug____> | huh, ringmark is a buggy test |
| 22:59 | <smaug____> | it is sad that people rely on such tests |
| 22:59 | <smaug____> | and also things like html5test |
| 22:59 | <othermaciej> | smaug____: what is buggy about ring mark? |
| 23:00 | <othermaciej> | smaug____: html5test is unfortunately becoming a big deal in mobile browser marketing, I wonder if it would be useful to give feedback to the test creators |
| 23:00 | <smaug____> | it is testing stuff which explicitly should not be there |
| 23:00 | <smaug____> | like touch events |
| 23:00 | <othermaciej> | smaug____: and for ring mark in particular, I have the ability to contact the people at Facebook who made it directly |
| 23:00 | <smaug____> | they should not be there on non-touch platforms |
| 23:01 | <othermaciej> | so you think its testing for touch events should be conditional? |
| 23:01 | <smaug____> | I've filed bugs on html5test to remove invalid tests |
| 23:01 | <othermaciej> | or it should not test that at all? |
| 23:01 | <smaug____> | and add some possibly useful tests |
| 23:01 | <othermaciej> | how does one file bugs on html5test? |
| 23:01 | <smaug____> | github |
| 23:01 | <othermaciej> | I'd like to suggest that they move FileSystem API to bonus points |
| 23:01 | <smaug____> | there is a link somewhere in html5test to github |
| 23:01 | <othermaciej> | since there exist popular platforms today with no user-visible filesystem |
| 23:02 | <smaug____> | othermaciej: there are already couple of bugs open about Filesystem api |
| 23:02 | <smaug____> | (btw, I think it should be discussed during TPAC what to do with filesystem api. I'd like to drop it) |
| 23:03 | <smaug____> | othermaciej: https://github.com/NielsLeenheer/html5test/issues/ |
| 23:03 | <othermaciej> | perhaps it should be moved to the new WG proposed for system app APIs |
| 23:03 | <smaug____> | well, I think we shouldn't have the proposed filesystem api at all ;) |
| 23:03 | <smaug____> | but something better |
| 23:04 | <zewt> | how? |
| 23:04 | <smaug____> | what how? |
| 23:04 | <othermaciej> | I would be in favor of dropping it |
| 23:04 | <zewt> | better how? |
| 23:05 | <zewt> | the spec needs a lot of reworking, but the API is generally fine |
| 23:05 | <smaug____> | see comment in webapps wg mailing list |
| 23:05 | <smaug____> | comments |
| 23:05 | <zewt> | could you be more specific? heh |
| 23:05 | <smaug____> | othermaciej: I think everybody else but google is favor of dropping it |
| 23:05 | <zewt> | hasn't been anything about fsapi in quite a while |
| 23:05 | <smaug____> | zewt: because no one really cares about it :) |
| 23:05 | <zewt> | it's a pretty important API to bridge the current gulf between web apps and native anything |
| 23:06 | <othermaciej> | if only Google wants to implement it, then it probably should not be a standards-track document |
| 23:06 | <othermaciej> | WebSQL got dropped for less... |
| 23:06 | smaug____ | tries to figure out where performance.memory is defined |
| 23:06 | <smaug____> | well, WebSQL was odd case, but rather obvious that it should be dropped |
| 23:06 | <zewt> | (debatable) |
| 23:07 | <zewt> | (but not really comparable) |
| 23:07 | <smaug____> | othermaciej: do you know if I can file bugs on ringmark somewhere? |
| 23:07 | <smaug____> | or just send emails to fb? |
| 23:07 | <othermaciej> | smaug____: I do not know, but I can personally send email to fb |
| 23:08 | <othermaciej> | smaug____: so if you mail me bugs I can pass them along, or I can ask about a way to file bugs |
| 23:08 | <othermaciej> | I'm on a plane right now so my mail and web are super slow |
| 23:08 | smaug____ | could send emails to schrep but that is probably not the right level of management to send emails to |
| 23:09 | <smaug____> | is toby ever here |
| 23:09 | <smaug____> | from fb |
| 23:09 | <othermaciej> | http://rng.io/about/ |
| 23:09 | <othermaciej> | gives info that might be relevant to sending feedback |
| 23:13 | <othermaciej> | chasing links, it looks like the only bug tracker is the Core Mobile Web Platform CG's issue tracker |
| 23:17 | <smaug____> | what is this performance.memory... |
| 23:20 | <sicking> | Hixie: i definitely think using *a* filesystem API for this might be a good solution |
| 23:21 | <sicking> | Hixie: i think the current google filesystem API is way more complex than what's needed for a filesystem API |
| 23:21 | <smaug____> | sicking: what that for Hixie or for zewt |
| 23:22 | <sicking> | smaug____: for hixie |
| 23:22 | <smaug____> | I agree *a* filesystem API is needed |
| 23:22 | <sicking> | <Hixie> sicking: can you elaborate on why you don't want to use the filesystem api for this? do you just not think we should have that api at all? |
| 23:22 | <othermaciej> | I'm not sure I agree that *a* filesystem API is necessarily needed, at least for all platforms |
| 23:23 | <smaug____> | othermaciej: that is possible |
| 23:23 | <othermaciej> | for platforms that don't expose a hierarchical filesystem to the user, it doesn't really make sense to have an API that works like that |
| 23:23 | <sicking> | othermaciej: in general, or for dragndrop? |
| 23:23 | <smaug____> | yup |
| 23:23 | smaug____ | still wonders what on earth is performance.memory |
| 23:24 | <zewt> | othermaciej: if they don't have any concept of that, then they wouldn't have any concept of "dragging in a directory" either |
| 23:24 | <othermaciej> | sicking: we had another conversation about filesystem API just now, I missed the original one with Hixie that I guess involved DnD |
| 23:24 | <othermaciej> | sicking: but I also don't think Drag & Drop makes sense on all platforms |
| 23:24 | <sicking> | othermaciej: i missed the later one :) |
| 23:24 | <othermaciej> | for instance, iOS has no drag * drop |
| 23:24 | <othermaciej> | and I do not think it even makes sense on a touch platform |
| 23:25 | <sicking> | othermaciej: agreed. I think that would simply result in not ever firing dragndrop events on iOS. Just like we'd never fire them in OSX if noone drops something |
| 23:25 | <zewt> | there are probably a bunch of things that I'd clean up in FS-API, and possibly some trimming, but it seems like the right direction |
| 23:25 | <othermaciej> | sicking: do you think it's appropriate to have all the interfaces relevant to DnD but just never invoke them on a platform with no DnD? |
| 23:26 | <othermaciej> | sicking: or would it be better to not expose the interfaces? |
| 23:26 | <othermaciej> | for FS API, I think it would be nutty to have all the interface objects but never let them be used in any way |
| 23:26 | <sicking> | othermaciej: oh. I suspect it makes sense that whatever interfaces exist for DND wouldn't exist on platforms that don't have DnD |
| 23:27 | <sicking> | othermaciej: we're mostly talking interface objects? Or is there more DnD API? |
| 23:27 | <zewt> | (eg. getMetadata seems unnecessary--it's redundant with simply creating a File) |
| 23:27 | <miketaylr> | smaug____: rwaldron (who isn't here right now) develops ringmark, you could email him rick⊙bc |
| 23:28 | <smaug____> | miketaylr: thanks |
| 23:28 | <othermaciej> | sicking: perhaps I should file a bug, because the spec is not very clear about what interfaces should be present or what the behavior should be on platforms with no DnD |
| 23:28 | <miketaylr> | np |
| 23:28 | <sicking> | othermaciej: On filesystems, I suspect what we need to do is to expose sandboxed filesystems to webapps. Similar to what chrome does. But it wouldn't be exposing a user-visible directory structure. It might not even be a real filesystem (chrome's FS API isn't actually backed by a filesystem) |
| 23:29 | <sicking> | othermaciej: but I don't like chromes FS API. I think we should propose a *much* simpler one |
| 23:29 | <othermaciej> | sicking: what's the benefit of making it look like a filesystem if it is not even backed by a filesystem? |
| 23:29 | <sicking> | othermaciej: the storage policy would be the same as what's used for WebSQL/IndexedDB |
| 23:30 | <sicking> | othermaciej: Mostly there are two advantages: 1. Many developers are very used to filesystems. Even for games that want to simply download and cache resources, saving them in a filesystem-like API is very natural for them |
| 23:30 | <othermaciej> | WebSQL and IndexedDB can store binary blobs just fine... |
| 23:31 | <othermaciej> | is it too complicated or confusing to use IndexedDB (let's say) for such a use case? |
| 23:31 | <zewt> | do IDB implementations store blobs out-of-line, eg. as their own file and not as a blob in the middle of a db file? |
| 23:31 | <sicking> | othermaciej: 2. URLs are hierarchical. Storing the files in a heirarchical storage area allows reading from that area directly using URLs |
| 23:32 | <sicking> | othermaciej: *anything* more complex than "just a filesystem" is "too complicated" |
| 23:32 | <othermaciej> | so blob urls don't cut it? |
| 23:33 | <sicking> | othermaciej: blob urls have to be generated on each run |
| 23:33 | <othermaciej> | filesystems are pretty complicated |
| 23:33 | <jsbell> | zewt: Chrome doesn't handle Blobs in IDB yet. :( |
| 23:33 | <sicking> | othermaciej: the nice thing about a filesystem url is that you can just read from the database directly |
| 23:33 | <sicking> | othermaciej: they don't need to be |
| 23:34 | <othermaciej> | hierarchical by-name read-write store for opaque binary objects seems like an ok concept |
| 23:34 | <othermaciej> | but I am sad at how many storage APIs the platform has already |
| 23:34 | <zewt> | i'm wary of database-backed systems for storing large data (eg. gigabytes of dynamically-patched game data); multiple layers of fragmentation, etc (but if IDB implementations mature and it's proven to "just work" then I'd probably get over that) |
| 23:34 | <sicking> | othermaciej: i haven't worried too much about filesystem because i feel the same way, "it's just syntax sugar on top of a database. use a library over IDB/websql" |
| 23:34 | <othermaciej> | does filesystem API give you URLs that persist from run to run? |
| 23:34 | <sicking> | othermaciej: i still think that's mostly true. But I think a filesystem is generally worth it |
| 23:34 | <sicking> | othermaciej: it does |
| 23:35 | <sicking> | othermaciej: filesystem://http://mysite.com/path/in/filesystem/to/file.jpg |
| 23:35 | <othermaciej> | is IndexedDB incapable of providing persistent URLs or a hierarchical namespace? |
| 23:35 | <zewt> | i don't think persistent URLs are very important, though, since it's easy to go path -> blob -> createObjectURL (for a nonpersistent blob) |
| 23:35 | <othermaciej> | I am not very familiar with it |
| 23:35 | <sicking> | othermaciej: incapable is a strong word |
| 23:35 | <othermaciej> | I guess it's a two-level question: |
| 23:35 | <sicking> | othermaciej: but keys can be anything, not just strings |
| 23:35 | <othermaciej> | (1) is it unable to do it in the current drafts? |
| 23:36 | <othermaciej> | (2) is it conceptually/technologically hard to add such features? |
| 23:36 | <jsbell> | The transaction overhead might scare off some developers. On the other hand, the transaction overhead is what you really need for multiple tabs from the same origin that are partying on the same data, so... |
| 23:36 | <othermaciej> | I don't really see how you can sanely offer read-write stream access w/o some form of transactional layer |
| 23:36 | <sicking> | othermaciej: (1) it's not possible currently (2) it's possible, but it won't be terribly clean |
| 23:37 | <sicking> | othermaciej: each "add this file to the filesystem" would be a transaction. Which makes it mostly invisible |
| 23:37 | <jsbell> | "Proof by example": http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api |
| 23:38 | <zewt> | jsbell: transactions and efficient, native files (ideal for large or growing files) are sort of mutually exclusive, though, since filesystem-level, cross-file transaction support is hit and miss (ntfs has transactional file access but I don't know much about that) |
| 23:38 | <othermaciej> | I might feel bad about "yet another storage api" if it did not have 22 new interfaces (adding on top of already existing reader and writer interfaces) |
| 23:38 | <jsbell> | zewt: +1, I share that concern. |
| 23:38 | <othermaciej> | sicking: filesystem API lets you write an existing file, no? |
| 23:38 | <othermaciej> | sicking: or read an existing file, by name |
| 23:38 | <sicking> | othermaciej: you mean, "not feel bad about ..."? |
| 23:38 | <othermaciej> | what if two tabs touch the same file at once? |
| 23:39 | <othermaciej> | sicking: "feel less bad about" |
| 23:39 | <sicking> | othermaciej: ah |
| 23:39 | <sicking> | othermaciej: you should look at my DeviceStorage proposal :) |
| 23:39 | <Hixie> | othermaciej: everything i know about the appcache stuff is http://goo.gl/VrQNF |
| 23:39 | <othermaciej> | pointer? |
| 23:39 | <sicking> | othermaciej: it's 3 interfaces currently. Probably will be 5 once it's fully capable |
| 23:39 | <sicking> | othermaciej: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI |
| 23:40 | <sicking> | othermaciej: currently it's a filesystemAPI + "API for getting access to a filesystem rooted in users pictures folder" |
| 23:40 | <sicking> | othermaciej: but the filesystem part can easily be broken out |
| 23:41 | <Hixie> | smaug____: websql got dropped because the editor of that spec wouldn't spec something without wide adoption, dunno if the editor of the other specs you mentioned fall into that category ;-) |
| 23:41 | <zewt> | othermaciej: 22? looking through the TOC I see 19 (still a lot), but 8 of those are Callback=FunctionOnly callback interfaces (which while I don't know where that's defined--it's not in webidl--it sounds like "you can only pass in a function and this doesn't actually expose an interface") |
| 23:41 | <zewt> | which would be 11 |
| 23:41 | <zewt> | not to say that's not still a lot :) |
| 23:42 | <othermaciej> | see, combining filesystem-as-virtual-local-hierarchical-storage and filesystem-as-way-to-access-directories-in-the-user's-filesystem is what makes it something that I'm not keen on |
| 23:42 | <othermaciej> | zewt: I am imagining that for the "I need to store some blobs in a hierarchy and access by name" use case, 1-2 interfaces are sufficient (building on top of File, FileReader, FileWriter and friends) |
| 23:43 | <zewt> | (but there are also sync and async interfaces; I don't think it's fair to count an API as double-the-interfaces just because it has sync worker support; though the sync-getMessage proposal might in principle mean we don't need any more sync APIs at all) |
| 23:43 | <zewt> | ignore those and you're at 7 |
| 23:43 | <othermaciej> | so even if we exclude the callback interfaces, we're still off by an order of magnitude |
| 23:43 | <zewt> | othermaciej: i do agree it can and should be simplified, though I'm not sure I'd go that far |
| 23:43 | <othermaciej> | yes, if you ignore 2/3 of the interfaces you get 1/3 as many |
| 23:43 | <sicking> | othermaciej: in what sense? You would prefer to have two separate APIs as to avoid author confusion about what they are working with? Or you want two separate APIs so that you can optimize for different usecases? Or something else? |
| 23:44 | <zewt> | yes, if I ignore interfaces that may not be needed and could be dropped, indeed I get less :) |
| 23:44 | <othermaciej> | the latter API is (a) not one that I'm sure we want to offer in Safari on any platform; and (b) more more complex than needed for the private-blob-store use case |
| 23:45 | <zewt> | (i suspect the FileSystem and Metadata interfaces could be dropped, too) |
| 23:45 | <smaug____> | Hixie: nope, they indeed don't fall into same category, which is why I said "WebSQL was [an] odd case" |
| 23:45 | <sicking> | othermaciej: i absolutely agree that if we add a filesystem API to be used for a sandboxed storage area, then it needs to be possible to implement *just* that. And not worry about access to pictures folder etc |
| 23:45 | <Hixie> | smaug____: i would hope that having an editor who cares about multiple vendor interop wasn't odd :-) |
| 23:45 | <zewt> | (FileSystem just stores a name, which doesn't seem needed, and Metadata is redundant with File) |
| 23:46 | <smaug____> | Hixie: well, Filesystem API is such case atm ;) |
| 23:46 | <sicking> | othermaciej: i also agree that the API shouldn't need to be meaningfully more complex out of desire to handle both cases |
| 23:46 | <othermaciej> | sicking: I'm on a plane using the in-flight wifi so your proposal is tragically slow to load |
| 23:46 | <sicking> | othermaciej: ah :) |
| 23:47 | <othermaciej> | sicking: otherwise I would be commenting on it instead of just hypothetically |
| 23:47 | <zewt> | (url? missed that) |
| 23:47 | <sicking> | othermaciej: i think we can solve all designed constraints here. But I agree we need a specific proposal before we can know for sure. I think the DeviceStorage API is close, but not quite there |
| 23:47 | <sicking> | zewt: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI |
| 23:47 | <smaug____> | Hixie: er, I guess I mean, FSAPI is opposite of what you did |
| 23:48 | <othermaciej> | my theoretical minimum set of interfaces: Directory, some placeholder interface to get the root local storage Directory, callback interface for enumerating a Directory |
| 23:48 | <sicking> | othermaciej: i think you can do it without a Directory object |
| 23:48 | <Hixie> | smaug____: oh, i agree, i'm just hoping that the odd case is fsapi, not websql :-) |
| 23:48 | <othermaciej> | I would also question whether a hierarchical namespace is truly needed |
| 23:48 | <sicking> | "hierarchical namespace"? |
| 23:48 | <Hixie> | nested Directory objects |
| 23:49 | <sicking> | i say we don't need that |
| 23:49 | <sicking> | DeviceStorage doesn't have it |
| 23:49 | <Hixie> | if you don't have nested Directory objects, it's not clear that you need Directory objects at all -- just stick the Files in a database |
| 23:49 | <othermaciej> | then you only need a FileStore interface, a callback interface to enumerate the Files in FileStore, and a hook to get the FileStore |
| 23:49 | <othermaciej> | (maybe you just new FileStore()) |
| 23:49 | <Hixie> | why isn't IndexDB that store? |
| 23:50 | <Hixie> | does it not handle Files? |
| 23:50 | <zewt> | well, you definitely need to be able to enumerate the files in a particular directory, but you don't necessarily need a Directory object to do that |
| 23:50 | <Hixie> | (Web Storage was that store for a while, but then we reverted to just text) |
| 23:50 | <othermaciej> | IndexedDB does not offer a persistent URL to refer to an entry |
| 23:50 | <othermaciej> | sicking says adding that would be awkward |
| 23:50 | <Hixie> | you just need to get a File out, no? then File can give you the url |
| 23:51 | <zewt> | (i don't understand the desire for persistent URLs either) |
| 23:51 | <othermaciej> | IndexedDB can in theory offer up blob: URLs but you have to make a new one each time |
| 23:51 | <othermaciej> | it would be nice to be able to store some markup referring to your stored resource items |
| 23:51 | <othermaciej> | without having to reconstitute the markup from a template each time |
| 23:52 | <Hixie> | aah |
| 23:52 | <Hixie> | i see |
| 23:52 | <Hixie> | i guess that makes sense |
| 23:53 | <Hixie> | that'd be useful for appcache too |
| 23:53 | <othermaciej> | It seems to me IndexedDB could offer than in principle, but I'm willing to believe it would be awkward to fit into the API |
| 23:53 | <othermaciej> | (indexeddb://http://mydomain.com/key/path |
| 23:54 | <jsbell> | Is the desire to mint URLs like that and be able to pass them around to other parts of the platform that consume URLs? |
| 23:55 | <zewt> | i think that's always the goal with URLs |
| 23:55 | <Hixie> | jsbell: images are a classic example |
| 23:55 | <sicking> | in particular it's hard to make relative URLs work |
| 23:55 | <othermaciej> | that's what I presume |
| 23:55 | <jsbell> | if so... yeah, figuring out how to reconcile that with the transaction model would require thought |
| 23:55 | <sicking> | i.e. you'd want "foo/bar/baz.html" to be able to link to a file |
| 23:56 | <sicking> | and "foo/bar/bizzle/hello.jpg" to link to another file |
| 23:56 | <othermaciej> | jsbell: not sure it's that complicated - http: has an asynchronous request/response model, indexeddb: or filesystem: could too |
| 23:56 | <zewt> | can't recall--is there a way for URLs to specify a protocol and a path, but no host? |
| 23:56 | <zewt> | which seems like what you'd want here |
| 23:56 | <othermaciej> | jsbell: it just has to give you one consistent state, asynchronously |
| 23:56 | <sicking> | while URLs into IDB probably would be something like "databasename/objectstore/key/objectproperty" |
| 23:57 | <sicking> | yeah, i think the transaction part is solvable. Though possibly higher overhead than the transactions that govern a filesystem |
| 23:57 | <sicking> | but that might not even be true |
