| 00:00 | <jsbell> | speaking of "databasename/objectstore/key/objectproperty" - the desire to read out just one property of an object has definitely come up as a pain point. |
| 00:03 | <othermaciej> | sicking: ok, loaded your proposal |
| 00:03 | <jsbell> | zewt: indexeddb:///databasename/etc with an optional domain that is usually blank (like file:///...)... and someday there may be a cross-domain permission model |
| 00:04 | <othermaciej> | sicking: I see ways to simplify further and some of the names are not my favorite but otherwise it's much closer to my design taste |
| 00:04 | <sicking> | othermaciej: i'm writing a new one which is more complete :) But you should be getting the basics of it. |
| 00:04 | <othermaciej> | sicking: not fully clear on what a DOMRequest is, is that a generic way to return an async result? |
| 00:04 | <sicking> | othermaciej: how would you simplify further? |
| 00:05 | <othermaciej> | sicking: I would say s/get/open/ s/getEditable/openForWrite/ or something |
| 00:05 | <sicking> | othermaciej: yeah. It's something we've used in a bunch of our new interfaces |
| 00:05 | <othermaciej> | as far as naming goes |
| 00:05 | <sicking> | http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIDOMDOMRequest.idl |
| 00:05 | <othermaciej> | I would look for a way to get rid of DeviceStorageCursor |
| 00:05 | <sicking> | othermaciej: how? |
| 00:05 | <othermaciej> | it looks like you defined it twice though |
| 00:06 | <othermaciej> | so might be over counting the interfaces |
| 00:06 | <zewt> | sicking: fwiw, a way to convert blob -> file (attaching a name and mtime, with mtime being optional with a reasonable default) might be nicer than "addNamed" |
| 00:06 | <othermaciej> | I think a way to add an item without giving a name is unnecessary |
| 00:06 | <zewt> | fs.add(blob.getFile("foo.txt")) |
| 00:07 | <othermaciej> | I think addNamed() should be create() |
| 00:07 | <sicking> | othermaciej: indeed, unnamed files only makes sense for the "user's pictures folder" usecase |
| 00:07 | <sicking> | othermaciej: so we'd subclass for that i think |
| 00:07 | <othermaciej> | does DOMRequest have events? |
| 00:07 | <othermaciej> | is there a spec for it? |
| 00:07 | <othermaciej> | I can't tell how it works and thus do not understand what cursor is |
| 00:08 | <zewt> | why would pictures be unnamed? |
| 00:08 | <sicking> | othermaciej: it's basically the same as IDBRequest with some IDB specific stuff removed |
| 00:08 | <othermaciej> | sicking: for the "user's pictures folder" it's not clear to me you want to offer writing |
| 00:08 | <othermaciej> | sicking: but if you do, then surely it is named writing that you want |
| 00:08 | <sicking> | othermaciej: if you're building a web based OS you do :) |
| 00:09 | <othermaciej> | sicking: if NSDOMRequest could fire "success" multiple times and had a "done" event for that case, no extra interface would be needed |
| 00:09 | <sicking> | othermaciej: and make the .continue() call implicit? |
| 00:09 | <othermaciej> | sicking: for the "web based OS" use case (one which is not a use case I'm currently working on), I don't see why writing a named file to the pictures folder is insufficient |
| 00:09 | <othermaciej> | sicking: yeah, you just get events when stuff is ready |
| 00:09 | <sicking> | othermaciej: wouldn't that just mean that you'd want to add a .stop() function? |
| 00:10 | <othermaciej> | sicking: maybe you even get an array so stuff is batched as appropriate |
| 00:10 | <othermaciej> | sicking: I feel like you want cancel() for any DOMRequest |
| 00:10 | <othermaciej> | it seems like a fundamental feature of an asynchronous request that you can cancel it |
| 00:10 | <sicking> | othermaciej: mm... possibly.. though that can be really hard to implement usefully in the general case |
| 00:11 | <sicking> | othermaciej: for database operations it's basically impossible to do sanely |
| 00:11 | <othermaciej> | well, cancel() might just mean that you don't get the callback but it's too late to stop the side effect |
| 00:11 | <othermaciej> | it's clearly impossible for an async API to promise you the side effect will be prevented |
| 00:11 | <othermaciej> | but it can promise not to invoke the callback if it hasn't already |
| 00:12 | <sicking> | seems less racy then to promise to not remove the sideeffect |
| 00:12 | <othermaciej> | (or not to invoke it again) |
| 00:12 | <sicking> | which basically means that .cancel() == .removeEventListener() |
| 00:12 | <sicking> | except in the case of cursors, sure |
| 00:12 | <othermaciej> | fair enough |
| 00:12 | <sicking> | othermaciej: anyway, this is a detail i think |
| 00:12 | <othermaciej> | yeah |
| 00:12 | <zewt> | i wouldn't want that in all cases, eg. cancelling XHR should make a best effort to actually stop the request |
| 00:13 | <othermaciej> | I have many thoughts on details but I like this direction much better than FileSystem API |
| 00:13 | <sicking> | othermaciej: interesting to hear that you like the general approach though. I'd like to send it to the webapps list specifically for the use case of sandboxed filesystem |
| 00:13 | <othermaciej> | canceling a file read should also attempt to stop reading further bytes from disk |
| 00:13 | <sicking> | othermaciej: but i haven't had time (and won't for another little while) |
| 00:13 | <zewt> | othermaciej: well, that's not strictly a side-effect, since it has no visible effects |
| 00:13 | <zewt> | where XHR often does |
| 00:13 | <othermaciej> | can't promise what other Apple folks would think, but I suspect we'd be more warm to this than FileSystem |
| 00:14 | <sicking> | othermaciej: oh, you should probably look at the FileHandle API too |
| 00:14 | <othermaciej> | is that different from FileReader / FileWriter? |
| 00:14 | <sicking> | othermaciej: unless you have seen it already, i sent a early draft to the webapps mailinglist |
| 00:14 | <sicking> | yes |
| 00:15 | <sicking> | it's in place of FileWriter |
| 00:15 | <sicking> | http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0886.html |
| 00:15 | <othermaciej> | ok |
| 00:15 | <othermaciej> | I'll have to look closer at both than and FileWriter |
| 00:15 | <sicking> | FileWriter has many bad problems IMHO. I enumerated most of them in that thread (not sure if it was in that email) |
| 00:16 | <sicking> | FileWriter suffers from being too close to FileReader, and I'm sad to admit to FileReader being poorly designed (my fault) |
| 00:17 | <sicking> | the problem is mostly syntactic in FileReader though. In FileWriter it doesn't provide enough primitives |
| 00:29 | <sicking> | Here's a more polished proposal which handles shallow directory enumeration: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI2 |
| 00:29 | <sicking> | names are hard |
| 00:33 | <othermaciej> | sicking: I stand by my suggestion that nested directories are unnecessary given the use cases |
| 00:33 | <sicking> | othermaciej: not sure what you mean by that |
| 00:34 | <othermaciej> | sicking: (they might be necessary for the "web-based OS" use case, but I would prefer that to be kept separate from the "web" use case) |
| 00:34 | <othermaciej> | sicking: I don't see why you need to have any containers other than the top-level one |
| 00:34 | <othermaciej> | for the case of "I want to stage some resources and refer to them by URL" |
| 00:35 | <jamesr> | what if you have a lot of resources? |
| 00:35 | <othermaciej> | therefore I do not understand why there is any form of directory enumeration in addition to enumeration of the top level |
| 00:35 | <othermaciej> | what if you do? |
| 00:36 | <othermaciej> | apps on OS X and iOS have a flat "Resources" directory in their app bundle and it seems sufficient even for apps with lots of resources |
| 00:36 | <jamesr> | i see a lot of subdirs in the Resources directory of /Applications/Safari.app/Contents/Resources |
| 00:37 | <othermaciej> | the .lproj dirs are a localization scheme that's transparent to the app |
| 00:37 | <jamesr> | $ find /Applications/Safari.app/Contents/Resources/ -type d | wc -l 136 |
| 00:37 | <jamesr> | no, there's more than .lproj dirs |
| 00:38 | <othermaciej> | others are likely files that are bundles |
| 00:38 | <othermaciej> | so their directory-nature is also mostly-opaque |
| 00:38 | <jamesr> | i see a manifest thing and a help thing just at a glance |
| 00:38 | <sicking> | othermaciej: so you are saying you don't want directories at all? |
| 00:38 | <sicking> | othermaciej: or just 1 level deep directories? |
| 00:39 | <othermaciej> | sicking: I think the root directory is the only one you need |
| 00:39 | <jamesr> | even though it's not sufficient for Safari.app ? |
| 00:39 | <jamesr> | i assume web apps have to deal with l10n |
| 00:39 | <othermaciej> | jamesr: those are both bundles and thus logically files |
| 00:39 | <othermaciej> | the API safari uses to access its resources offers a flat namespace |
| 00:40 | <sicking> | othermaciej: that's a pretty controversial position if you accept the need for filesystems |
| 00:40 | <othermaciej> | the relevant frameworks transparently overlay the localizations |
| 00:40 | <othermaciej> | I doubt web apps want that specific l10n scheme |
| 00:40 | <jamesr> | hm, so are you suggesting that the web API would support a specific l10n scheme? |
| 00:40 | <othermaciej> | sicking: I'm convinced that you need to store named data blobs that you can refer to by persistent URLs |
| 00:41 | <othermaciej> | jamesr: if you do your own l10n, it's not clear to me why you would need directories to do it - there's no real fundamental reason for OS X to do it that way, just quirk of history |
| 00:41 | <jamesr> | you're saying "it's good enough for OS X apps, except for these other cases that are handled by the framework" - so do you want to build that functionality into the framework itself to keep things looking flat? |
| 00:41 | <sicking> | othermaciej: one of the use cases that we had was people writing HTML editors and putting resource links in those documents that pointed to images and resources stored in the filesystem |
| 00:42 | <sicking> | othermaciej: it's pretty common on the web to store images in an images/ folder. So i would imagine people would want to do that here too |
| 00:42 | <othermaciej> | sicking: it's pretty common on the web to store images on a different server with a different hostname |
| 00:43 | <othermaciej> | sicking: but I'm not sure what relevance either of those approaches has to storing the files locally |
| 00:44 | <sicking> | othermaciej: the use case was basically to download a set of resources and have them use the same directory structure locally as you do on the website, edit locally, then upload to server |
| 00:45 | <othermaciej> | sicking: that would argue for N-deep directories |
| 00:45 | <sicking> | othermaciej: indeed |
| 00:45 | <othermaciej> | sicking: and ability to have multiple separate top levels |
| 00:45 | <sicking> | othermaciej: also indeed. The proposal has named toplevels |
| 00:45 | <sicking> | DeviceStorage getSandboxedFilesystem(DOMString filesystemName); |
| 00:45 | <othermaciej> | which ends at an API that I think is more complex than I'm interested in implementing |
| 00:46 | <sicking> | othermaciej: the API doesn't actually get more complex because you have nested directories |
| 00:46 | <sicking> | see https://wiki.mozilla.org/WebAPI/DeviceStorageAPI2 |
| 00:47 | <sicking> | the only thing that is added because of directories at all is 2 functions and an optional "directory" argument to two other functions |
| 00:47 | <sicking> | both are needed for 1-deep directories |
| 00:47 | <othermaciej> | you just showed me the simpler version that lacks that feature and the more complex version that has it |
| 00:47 | <sicking> | nothing extra is added for n-deep directories |
| 00:47 | <othermaciej> | (and which btw is bad OO design in the way it handles directories) |
| 00:48 | <sicking> | othermaciej: i'm really not sure that we need to build OO design around string concatenation |
| 00:48 | <sicking> | i actually think that's the main mistake in the google filesystem API |
| 00:48 | <othermaciej> | if string concatenation is sufficient, then why can't the client do it? |
| 00:48 | <othermaciej> | just allow a "/" character in filenames |
| 00:48 | <sicking> | othermaciej: most of the API does just that |
| 00:49 | <sicking> | othermaciej: the only additional thing was that people wanted to do shallow enumeration. That's the last two functions |
| 00:49 | <othermaciej> | I think having enumeration methods on DeviceStorage which take a token representing a directory is cheating |
| 00:49 | <othermaciej> | it would be like folding the FileHandle interface into DeviceStorage |
| 00:49 | <sicking> | is cheating bad? |
| 00:50 | <sicking> | if cheating == simple then cheating == good ;-) |
| 00:50 | <othermaciej> | to quote myself from a few weeks ago, "the web platform has enough 'war' in it, let's not add more" |
| 00:50 | <sicking> | how do you mean? |
| 00:51 | <othermaciej> | I mean using an opaque token with global methods to represent the named object is a more confusing design than an object with methods |
| 00:51 | <othermaciej> | to be fair, it is the Unix libc design, but at least it is done that way consistently |
| 00:52 | <othermaciej> | anyway, it would be better to have these discussions in a forum where more folks can participate |
| 00:52 | <sicking> | indeed |
| 00:52 | <othermaciej> | I like simple, I'm not yet convinced you need multiple top levels or that you need support for directories at anything more than a naming convention level (i.e. not clear why you need to enumerate) |
| 00:54 | <sicking> | othermaciej: if we don't need enumeration then i agree the API should be simplified. I think it'll be tough to sell a filesystem-like API without directories and enumeration though. Especially since IMO the main benefit of a filesystem API over indexedDB is that developers (not users) are used to dealing with directories |
| 00:55 | <sicking> | errr |
| 00:55 | <sicking> | are used to dealing with full filesystems as resource storage |
| 00:55 | <othermaciej> | sicking: that's kind of why I dislike thinking of it as a filesystem API - it leads people to expect complexity that does not seem fundamentally necessary for the relevant use cases |
| 00:55 | <sicking> | I'm definitely of the opinion that a filesystem is just a poor man's database |
| 00:56 | <othermaciej> | and I'm of the opinion that poor men don't need a rich api |
| 00:56 | <sicking> | othermaciej: heh |
| 00:57 | <othermaciej> | I said that to be funny, but I'm also kind of serious |
| 00:58 | <othermaciej> | is the goal is a simplified / dumbed down version of something you can already sort of do, then it shouldn't have a lot of features |
| 00:58 | <zewt> | i think by far the most important part of a filesystem API is to close the disconnect between websites and the user's filesystem and native apps; sandbox-only filesystem APIs aren't very interesting |
| 00:59 | <sicking> | othermaciej: indeed. But there's a range of complexity here. Finding the right points is the trick |
| 00:59 | <othermaciej> | zewt: that's a valid way of thinking, though such an API is a bad fit when there is no "the user's filesystem" |
| 01:00 | <othermaciej> | which is true on iOS and semi-true for sandboxed apps on OS X |
| 01:00 | <zewt> | othermaciej: when there's no user filesystem, apis connected to the concept just aren't activated |
| 01:01 | <zewt> | nothing really unusual there, i think |
| 01:01 | <othermaciej> | that API can be as complex as it likes, but it would likely be one we don't implement |
| 01:01 | <othermaciej> | so I wouldn't have much input other than to avoid mandating it in specs we may want to implement |
| 01:02 | <othermaciej> | thus the potential appeal of something like DeviceStorage, as the sandboxed file store use case is one I could be sold on, with a sufficiently simple interface |
| 01:32 | <sicking> | othermaciej: i agree with a lot of what you say. And I think the DeviceStorage API is very simple, even in the face of directories. We can argue whether directories are needed, but ultimately they are a pretty small part of the API, though of course non-trivial to implement |
| 01:33 | <sicking> | othermaciej: the only really hard part of the API is FileHandle. But I think you can make a pretty strong case for that filemanipulation is needed |
| 01:35 | <othermaciej> | sicking: haven't looked at FileHandle yet, but if it supports more than "write the file atomically from this blob/string/array/whatever" and "write to the file as a non-seekable stream", I would want to hear the use cases for that |
| 01:35 | <sicking> | othermaciej: it's mostly that. But it's also "read this data from the file, then write that data from the file, while keeping the file open inbetween to ensure that noone else modifies the file inbetween" |
| 01:36 | <othermaciej> | sicking: transactions, eh? |
| 01:36 | <sicking> | errr. "read this data from the file, write that data to the file (where the written data is based on the read data)..." |
| 01:36 | <othermaciej> | it's not totally clear to me that atomic read-write-modify is needed |
| 01:36 | <sicking> | othermaciej: no, no rollback, just the ability to keep the file open |
| 01:37 | <othermaciej> | I don't know if I understand the use case |
| 01:37 | <othermaciej> | you said "to ensure that noone else modifies the file inbetween" |
| 01:37 | <othermaciej> | on native operating systems, the way to ensure that is write to a whole new file, then count on rename being atomic |
| 01:38 | <sicking> | or you open with exclusive access, no? |
| 01:38 | <sicking> | crap, gotta run |
| 01:38 | <sicking> | there's usecases in the thread i pointed you to |
| 01:38 | <othermaciej> | exclusive access is applicable only when creating |
| 01:39 | <othermaciej> | at least on unix |
| 01:39 | <sicking> | but yes, my argument is that atomic read-modify-write is needed |
| 01:39 | <sicking> | as is fsync |
| 01:39 | <zewt> | othermaciej: atomic read/writes aren't done with rewriting and renaming, it's done with locks |
| 01:39 | <othermaciej> | there's no such thing as opening a file in a way that prevents other processes from opening it at the same time |
| 01:39 | <othermaciej> | well, native apps don't really have atomic read-modify-write |
| 01:39 | <zewt> | rather, ensuring other files don't write to it--you use rewrites and renames for transactional writes (when you want all-or-nothing writes) |
| 01:40 | <othermaciej> | zewt: rename is the only safe way to do it |
| 01:40 | <zewt> | it's far too expensive for general writes |
| 01:40 | <othermaciej> | the locking-based ways to do it either fail or require all sorts of trickery in what you put in the file |
| 01:41 | <othermaciej> | the only cases I know of that do "general writes" of that sort are databases |
| 01:41 | <othermaciej> | and attempting to implement a database on top of DeviceStorage would be insane |
| 01:41 | <zewt> | locking works when you control all of the readers and writers, when you don't you have to depend on the OS (and whether that works depends on the OS, and the network FS if any) |
| 01:41 | <othermaciej> | random-access writing a file is simply not safe |
| 01:42 | <othermaciej> | I'm just saying, native apps don't need this, so why do web apps? |
| 01:42 | <othermaciej> | use case! |
| 01:42 | <othermaciej> | (or rather, native apps generally only do this via a database-like api, which is offered elsewhere in the platform) |
| 01:42 | <zewt> | don't follow--native apps need safe writes all the time (which is one big reason lots of people use sqlite) |
| 01:42 | <othermaciej> | (or they are just broken) |
| 01:43 | <othermaciej> | sure, and indexeddb and websql do that |
| 01:43 | <othermaciej> | but where do you need it in the "game downloads its resources" use case? |
| 01:43 | <zewt> | but ultimately, for general-purpose, unstructured files, even if you ignore the multiple-users issue, there's no way to get safe writes when system crashes enter the picture |
| 01:43 | <othermaciej> | or the "stage mail uploads" use case? |
| 01:43 | <othermaciej> | or the "download a site, edit it, and upload" use case? |
| 01:43 | <zewt> | since nobody is transactional for that |
| 01:44 | <othermaciej> | right, unless you have a transaction model you built yourself, it's unsafe to do random-access file writes |
| 01:44 | <zewt> | adding a file to a ZIP, etc |
| 01:45 | <zewt> | updating big game data files with deltas/block hashes/whatever |
| 01:45 | <zewt> | afk, food |
| 02:31 | <MadPig> | So... who's in charge of HTML 5 Audio? |
| 02:32 | <Hixie> | what is HTML 5 Audio? |
| 02:33 | <MadPig> | The audio part of HTML 5. |
| 02:33 | <Hixie> | ok let me rephrase, what do you mean by "HTML 5" and what do you mean by "the audio part"? |
| 02:33 | <Hixie> | (not trying to be difficult, there are at least three things that you might mean by "HTML5" and several things that might be "audio") |
| 02:33 | <MadPig> | Sigh... |
| 02:34 | <MadPig> | I don't know what I mean. I assumed that there was only one standard of HTML 5. |
| 02:34 | <Hixie> | "HTML 5" isn't a standard |
| 02:34 | <MadPig> | And that it's pretty stable by now. |
| 02:34 | <MadPig> | "Draft" which isn't really a "draft", or whatever. |
| 02:34 | <Hixie> | there's the "HTML" standard which has an <audio> element, the guy "in charge" of that would be me |
| 02:35 | <MadPig> | Why did you not include panning in the specs? :-| |
| 02:35 | <Hixie> | there's the "HTML5" draft at the W3C which has their version of <audio>, not sure who would be "in charge" of that, probably the HTMLWG as a whole |
| 02:35 | <zewt> | (i suspect whatever it is he's talking about is not actually <audio>...) |
| 02:35 | <MadPig> | Hmm... that is very confusing. |
| 02:35 | <Hixie> | and there's the "Web Audio API" which people say is "part of HTML5", which does effects |
| 02:35 | <MadPig> | zewt: It is. |
| 02:35 | <Hixie> | and which has panning, i believe |
| 02:36 | <MadPig> | Hmm... |
| 02:36 | <Hixie> | not sure who is in charge of that exactly |
| 02:36 | <MadPig> | There is a lot of "Legend has it that..." kind of things related to "HTML 5". |
| 02:36 | <MadPig> | Nobody is sure. It's unclear what is official. |
| 02:36 | <MadPig> | Etc. |
| 02:36 | <Hixie> | anyway, as for <audio>, it doesn't have panning because it's just an audio file playback api |
| 02:37 | <MadPig> | Well, it should not be IMO. |
| 02:37 | <MadPig> | It should allow for panning since it's crucial for games. |
| 02:37 | <Hixie> | for games, you want the Web Audio API, not <audio> |
| 02:37 | <Hixie> | https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html |
| 02:38 | <MadPig> | (Any action game will require many "voices" to be played at the same time (even of the same sample), and fully supported panning.) |
| 02:38 | <MadPig> | Well... |
| 02:38 | <Hixie> | yeah, that's what Web Audio is for |
| 02:38 | <MadPig> | So it's part of HTML 5? |
| 02:38 | <MadPig> | Why two different things? |
| 03:49 | <Hixie> | d'oh, he left |
| 03:57 | <othermaciej> | maybe he meant the <audio> element and related interfaces? |
| 03:58 | <Hixie> | he did, we had a whole conversation |
| 03:58 | <Hixie> | but i had a Computer Issue and he left while i was trying to deal with it |
| 07:54 | <jgraham> | darobin: Wait, what? Your Process involves deleting branches on github? That doesn't seem ideal |
| 07:54 | darobin | looks at jgraham, looks at coffee, wonders wah? |
| 07:55 | <jgraham> | Well, more nessy's process |
| 07:55 | <jgraham> | "The following branches have been merged (and are now gone from github |
| 07:55 | <jgraham> | to allow for the next round):" |
| 07:55 | <jgraham> | It is the parenthetical I am wondering about |
| 07:55 | <darobin> | deleting feature branches after they have been merged is not uncommon |
| 07:55 | <jgraham> | Really? |
| 07:55 | <darobin> | yeah |
| 07:55 | <jgraham> | It seems pretty silly to me |
| 07:56 | <darobin> | in fact git-flow does it by default |
| 07:56 | <darobin> | why? the full history is kept |
| 07:57 | <jgraham> | Because it seems confusing if someone else has a local branch that tracks that remote |
| 07:57 | <darobin> | you mean with local changes? |
| 07:57 | <jgraham> | (indeed, if you "merge" using rebase, the commits on that branch will eventually be lost) |
| 07:57 | <darobin> | ah, gotcha |
| 07:58 | <darobin> | yes, the problem isn't so much deleting branches — it's sharing feature branches in the first place |
| 07:58 | <jgraham> | That seems like a highly necessary part of any multi-person workflow |
| 07:59 | <darobin> | no, you don't collaborate on a feature branch |
| 07:59 | <jgraham> | … |
| 07:59 | <darobin> | the multi-person workflow is about the branches you merge to |
| 08:00 | <darobin> | there should be a health warning in there "These are feature branches being shared so that you can see where we're at. Be warned that they may be deleted without warning." |
| 08:00 | <jgraham> | There is clearly some part of the workflow that we do differently here :) |
| 08:00 | <darobin> | heh |
| 08:00 | <jgraham> | But if there is a team of 5 people all working on feature A, there has to be a branch where they can all push changes to feature A |
| 08:01 | <darobin> | when you use git-flow (which admittedly we don't) and in many uses of git in general, feature branches are branches you keep locally for a change you're working on but haven't finished |
| 08:01 | <darobin> | not every feature is a feature branch :) |
| 08:02 | <darobin> | but either way, you should take that up with silvia — at least she's had her coffee :) |
| 08:02 | <jgraham> | So in git-flow parlance "feature branch" is another name for a local branch that doesn't track a remote? |
| 08:02 | <jgraham> | Or does it track a remote? |
| 08:04 | <darobin> | I think that the second you have a branch that can be tracking a remote, you're sort of making the promise that you won't delete it |
| 08:04 | <darobin> | I don't believe I've ever pushed a feature branch on purpose |
| 08:05 | <darobin> | (the feature/whatwg branch would be a special case here of course) |
| 08:05 | <jgraham> | You mean tracked as a remote? |
| 08:05 | <darobin> | the branches that silvia is using are all about merging in stuff |
| 08:06 | <darobin> | I'm not sure which of my lines your "you mean" refers to :) |
| 08:06 | <darobin> | but then again, as I've mentioned: coffee |
| 08:06 | <jgraham> | Heh |
| 08:06 | <jgraham> | Don't let me get in your way :) |
| 08:08 | <zcorpan> | annevk: how is --pubdate="$(PUBDATE)" intended to be used in MakeFile? |
| 08:09 | <annevk> | try make PUBDATE="15 Sep 2012" or some such |
| 08:09 | <annevk> | I wonder if html5-diff is still necessary though |
| 08:10 | <annevk> | everyone should be up to speed by now |
| 08:10 | <zcorpan> | sonuds like you're out of touch with the real world :-P |
| 08:11 | <zcorpan> | browse sitepoint forums some day |
| 08:12 | <annevk> | I like my world |
| 08:37 | <Tuju> | I've a problem with xml schema, anyone able to help me? I'm trying to define a type with integer range limitation + an attribute |
| 08:37 | <Tuju> | % xmllint --noout --schema formats/config/apache/httpd/2.2/config.xsd tests/configs/domains/modweb.org.conf.xml |
| 08:37 | <Tuju> | formats/config/apache/httpd/2.2/config.xsd:226: element simpleType: Schemas parser error : Element '{http://www.w3.org/2001/XMLSchema}complexContent';: The content is not valid. Expected is (annotation?, (restriction | extension)). |
| 08:39 | <jgraham> | Tuju: Pretty sure if you are trying to use XML schema you are beyond help :) |
| 08:39 | <jgraham> | But whatever help you can get is more likely to come from some XML-specific channel |
| 08:39 | <jgraham> | Not here |
| 08:39 | <Tuju> | jgraham: there is nothing wrong with xml imo. |
| 08:40 | <Tuju> | it only has a bad reputation. |
| 08:51 | <darobin> | Tuju: regardless of XML's merits or lack thereof, I think you're very unlikely to find the appropriate help for your issue here — it's not exactly the community for XML Schema |
| 08:52 | <Tuju> | i came here because earlier this was the only place anyone was able to comment my xml stuff |
| 08:52 | <Tuju> | but my intention is not to spam around, if it's out of scope, i'm happy to take my issue elsewhere. :) |
| 08:53 | <darobin> | Tuju: libxml2's support for XML Schema is incomplete at best, and unlikely to ever get fixed AFAIK |
| 08:53 | <darobin> | so if you really wish to use XML Schema, you should use another validator |
| 08:54 | <Tuju> | ah, that i didn't know. |
| 08:54 | <darobin> | the error you're getting is libxml2 complaining that the schema you're feeding to it is not a valid schema |
| 08:54 | <Tuju> | my skills are so limited that i would have bet that it's my mistake. |
| 08:55 | <Tuju> | that file where those exist is already quite long and has worked so far. |
| 08:55 | <darobin> | well, if you think it's a valid schema, given that it comes from Apache you should probably try it out with Xerces or whatever it is they use nowadays |
| 08:55 | <Tuju> | but with limited set of features used. |
| 08:56 | <darobin> | Tuju: frankly, XML is fine for a lot of stuff, but XML Schema is a rather dreadful piece of technology |
| 08:56 | <Tuju> | darobin: what comes from apache? |
| 08:56 | <darobin> | so I would recommend staying away from it as much as you can, *especially* if you're not an XML expert |
| 08:56 | <Tuju> | i wouldn't mind to become one :) |
| 08:56 | <Tuju> | it could be useful... |
| 08:56 | <darobin> | the config.xsd seems to come from Apache (based on the path) |
| 08:57 | <Tuju> | nope, i wrote that one. |
| 08:57 | <Tuju> | but yes, that content eventually came from there. |
| 08:57 | <darobin> | ah, ok, then it's possible you've made a mistake — writing XSD by hand is highly error-prone, and writing XSD with a tool is buggy at best |
| 08:58 | <Tuju> | i made plenty of bugs into that but gradually got them ironed out |
| 08:58 | <darobin> | if you do want to become an XML expert, learn all that you can do with XML without XML Schema, and only then look at XML Schema |
| 08:58 | <Tuju> | but it's still far from complete. |
| 08:58 | <darobin> | otherwise it'll warp any understanding you may have of the tech |
| 08:59 | <Tuju> | could be true. i just see that schemas are integral part of it. |
| 08:59 | <darobin> | if you think XML Schema is an integral part of XML, you will become a Java expert but never an XML expert :) |
| 09:01 | <Tuju> | uuuh, i would rather cut my wrists... |
| 09:01 | <Tuju> | looked at that xerces thingy, is there a cli tool for it? my fedora pkg search didn't find one. |
| 09:02 | <Tuju> | thou libs are included |
| 09:05 | <zcorpan> | can anyone tell me what materially changed in http://html5.org/r/7244 ? |
| 09:06 | <zcorpan> | the content model? |
| 09:07 | <zcorpan> | seems so |
| 09:30 | <Stevef_> | darobin: think i inadvertently overworte your change to https://www.w3.org/Bugs/Public/show_bug.cgi?id=18245 |
| 09:32 | <Stevef_> | darobin: were you assigning or unassigning yourself to the bug? |
| 09:32 | <darobin> | and you will pay dearly for that Stevef_! |
| 09:32 | <darobin> | I was assigning it to me, but it's no biggie |
| 09:32 | <Tuju> | darobin: i got it working |
| 09:32 | <Tuju> | with xmllint |
| 09:32 | <darobin> | if you update it, since you agree that it's a .next thing, can you assign it to the html.next product please? |
| 09:32 | <Tuju> | ho, i'm good. |
| 09:32 | Tuju | hugs himself. |
| 09:32 | Tuju | taps his own back. |
| 09:33 | darobin | gives Tuju a RelaxNG cookie |
| 09:33 | Tuju | whees! |
| 09:33 | <Stevef_> | darobin: i have already paid so dearly for my past transgressions that i have nothing left to give, yes will reassign |
| 09:33 | <darobin> | Stevef_: I'm certainly interested in looking more deeply into this, I was under the impression that this could be done with existing tech without needing support from the browser |
| 09:33 | <darobin> | but if I'm wrong it's certainly something we can do something about |
| 09:34 | <jgraham> | Stevef_: Sounds like a speech you should save for your last words :) |
| 09:34 | <darobin> | "Yes Will Reassign" sounds like a great epitaph |
| 09:34 | <darobin> | (or not) |
| 09:35 | <Stevef_> | darobin: it can be done with ARIA, but at least some people would prefer it be done via a HTML feature |
| 09:35 | <darobin> | Stevef_: right, that's what I thought, and IIRC many of the "big" implementations of tabs do it with ARIA |
| 09:35 | <darobin> | I'm happy to chat about the tradeoffs — but just in the .next timeframe :) |
| 09:35 | <Stevef_> | jgraham: one never knows when one's last words may be uttered... |
| 09:36 | <darobin> | at which point annevk ominously drops off |
| 09:36 | <darobin> | I told him this URL thing wasn't any good for him |
| 09:37 | <Stevef_> | darobin: its not a priority at the moment, I commented as I wanted to respond to the pure CSS view as I said in bug, its an old issue that has been postponed for now |
| 09:37 | <darobin> | Stevef_: cool, ta |
| 09:39 | <darobin> | Stevef_: I'm on the bug right now — I'll reassign and move to .next |
| 09:39 | <Stevef_> | i have already moved |
| 09:39 | <darobin> | really? it was telling me not... |
| 09:40 | <darobin> | well — it seems to be in a consistent state now anyway :) |
| 10:17 | <zcorpan> | http://dev.w3.org/cvsweb/html5/html4-differences/Overview.src.html.diff?r1=1.192;r2=1.193 |
| 12:06 | <AryehGregor> | Wait, is DOM4 still authoritative these days, or should I be editing something else if I want to make changes? |
| 12:06 | AryehGregor | looks for annevk or Ms2ger |
| 12:27 | <annevk42> | AryehGregor: use https://github.com/whatwg/dom |
| 12:27 | <annevk42> | AryehGregor: once you push the webpage will get updated automatically |
| 12:27 | <annevk42> | AryehGregor: webpage being http://dom.spec.whatwg.org |
| 12:27 | <AryehGregor> | annevk42, okay. Is that what implementers are using, or is this an independent fork that will cause havoc and confusion? |
| 12:28 | <annevk42> | we'll see |
| 12:31 | <annevk42> | AryehGregor: they're implementing based on it, e.g. createHTMLDocument()'s now optional argument |
| 12:32 | <annevk42> | AryehGregor: afaict implementors implement whatever is maintained |
| 12:32 | <AryehGregor> | So in other words, it's an independent fork that will cause havoc and confusion, but hopefully it will win? |
| 12:32 | <annevk42> | I don't know, I know I can't join the W3C so I can't edit their specs |
| 12:33 | <AryehGregor> | You don't want to join as an Invited Expert because that means giving over your copyright or something? |
| 12:33 | <annevk42> | right |
| 12:38 | <AryehGregor> | Could you use a CG instead? |
| 12:39 | <annevk42> | might publish them through the WHATCG |
| 12:39 | <annevk42> | but that doesn't really seem needed for now |
| 12:39 | <annevk42> | only for FSA-style stuff |
| 12:40 | <annevk42> | which I'll let Hixie pioneer |
| 12:51 | Ms3ger | summons jsbell |
| 12:53 | <Ms3ger> | (Only intermittently around until Monday or so, fwiw) |
| 12:56 | <odinho> | What's with all them numbers, annevk42 and now Ms3ger |
| 12:57 | <darobin> | yeah it's stupid, it's should clearly be annevkLS and MsLSget |
| 12:57 | <darobin> | *MsLSger |
| 13:17 | <zcorpan> | was there a bug filed about listing all events in the html spec? |
| 13:20 | <smaug____> | does anyone know what performance.memory is? |
| 14:19 | <zcorpan> | anyone feel like reviewing html5-diff before i say that i'm done (in a few minutes)? :-) |
| 14:19 | <zcorpan> | http://dev.w3.org/cvsweb/html5/html4-differences/Overview.src.html |
| 14:30 | <zcorpan> | (if you find issues, please file bugs, i'll fix it for the next publication) |
| 14:32 | <[tm]> | zcorpan: I will definitely take a look |
| 14:32 | <[tm]> | but I can't until tomorrow or so |
| 14:32 | <zcorpan> | [tm]: thanks! |
| 14:32 | <[tm]> | right now I am watching anne give a presentation |
| 14:32 | <zcorpan> | right now i'll call it a day |
| 14:33 | <zcorpan> | see you guys on monday :-) |
| 14:33 | <[tm]> | chheers |
| 15:29 | <jarek> | Hi |
| 15:29 | <jarek> | I have just found this spec: https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html |
| 15:29 | <jarek> | does it mean that SMIL is definitely dead now? |
| 15:56 | <cabanier> | hixie: I notice that not all images in the Canvas2D spec are checked in with SVN. |
| 15:56 | <cabanier> | hixie: could you add them so we can bring them into the W3 spec? |
| 15:56 | <cabanier> | hixie: also, do you have the original artwork? |
| 15:57 | <Hixie> | zcorpan: the ruby change was quite substantial; the spec went from basically having a trivial ruby feature to one that covers most of the use cases, by changing the content model and processing/rendering model. parsing didn't change. |
| 15:59 | <Hixie> | cabanier: they should be, but yeah, i can look into it. Can you send me an e-mail? |
| 15:59 | <Hixie> | cabanier: what do you mean by "original artwork"? |
| 16:00 | <Hixie> | actually don't worry about e-mail |
| 16:01 | <Hixie> | added them |
| 16:02 | <Hixie> | bbiab |
| 16:13 | <Ms3ger> | jsbell! |
| 16:13 | <jsbell> | eeeek! |
| 16:13 | <jsbell> | Wait... *3* ? |
| 16:13 | <Ms3ger> | You complained about an IDB test while I was offline? |
| 16:13 | <jsbell> | Yeah, sec... |
| 16:16 | <jsbell> | Ms3ger: http://w3c-test.org/webapps/IndexedDB/tests/submissions/Ms2ger/idbfactory_open9.htm has a test that IDBFactory.open() throws when version is >= 2^53. I agree with the sentiment, but it's neither in the spec nor did I see a spec bug. |
| 16:16 | <Ms3ger> | Did you look at WebIDL? |
| 16:17 | <jsbell> | *sigh* |
| 16:17 | <odinho> | Hmm... *testing* |
| 16:18 | <odinho> | yay green. |
| 16:18 | <jsbell> | Ah yes, there it is. |
| 16:18 | <jsbell> | *shakes fist at binding code* |
| 16:18 | <Ms3ger> | Good :) |
| 16:18 | <Ms3ger> | Not sure why you were looking anywhere else ;) |
| 16:18 | <Ms3ger> | Need to go now, though |
| 16:19 | <odinho> | okay, it's depressing staying longer at work now, so I'll go. |
| 16:19 | <odinho> | Hmm. at the same time even. |
| 19:55 | <jgraham> | smaug____: Isn't performance.memory the set of mostly-frightening requests that Zynga made |
| 19:55 | <jgraham> | ? |
| 19:56 | <jgraham> | http://lists.w3.org/Archives/Public/public-web-perf/2012Sep/0016.html |
| 19:56 | <jgraham> | Or that doesn't actually mention performance.memory anywhere so maybe not |
| 19:57 | <jgraham> | What's the context for your question? |
| 19:57 | <smaug____> | jgraham: ringmark test |
| 20:15 | <jgraham> | smaug____: Oh who knows then |
| 20:16 | <jgraham> | That is a walking disaster area |
| 20:20 | <jgraham> | smaug____: But I don't see it there either |
| 21:38 | <sicking> | Hixie: why can't I find any callers of "jump to a code entry-point"? I'm trying to figure out how "entry script" is actually intended to work |
| 21:41 | <sicking> | oh, it's just called "jump" in the text |
| 21:41 | <Hixie> | sicking: one sec |
| 21:41 | <sicking> | Hixie: nm |
| 21:42 | <Hixie> | sicking: clicking on the bold <dfn> text will get you a backref list btw |
| 21:42 | <Hixie> | sicking: (only works usefully on the single-page copy of hte spec) |
| 21:42 | <sicking> | Hixie: only if i want to wait ages for the page to load |
| 21:42 | <sicking> | Hixie: i always read the spec with ?slow-browser |
| 21:42 | <Hixie> | firefox is pretty fast these days on the spec isn't it? |
| 21:43 | <sicking> | Hixie: no, it's just pretty fast these days ;-) |
| 21:43 | <Hixie> | well it's been fast for longer than it's been fast specifically on the spec, which is why i put it that way :-) |
| 21:44 | <sicking> | Hixie: still takes 20 some seconds for me to get it fully responsive |
| 21:44 | <sicking> | measured between my thumb and index finger |
| 21:45 | <Hixie> | it does seem to hang the browser more than it does in chrome, weird |
| 21:45 | <Hixie> | i recommend just leaving it open in the background |
| 21:45 | <Hixie> | that's what i do :-) |
| 21:45 | <Hixie> | (once the page is loaded, firefox seems to be way better on it than chrome) |
| 21:46 | <Hixie> | (though resizing the browser window isn't so hot) |
| 21:46 | <Hixie> | (yikes) |
| 21:47 | <sicking> | Hixie: i have too much ADD to leave too many tabs open :) |
| 21:48 | <Hixie> | heh |
| 21:48 | <sicking> | Hixie: not saying that we couldn't do better with the spec from the gecko side. But this is why i have the ?slow-browser version bookmarked |
| 21:49 | <Hixie> | fair enough :-) |
| 21:49 | <sicking> | but i did remove it in order to find the back-refs here |
| 22:16 | <jonathanj> | hello, with html5lib.parse(some_xhtml, treebuilder='lxml') i get attributes like this: xmlU0003Alang |
| 22:18 | <zewt> | a fun mistake is hitting inspect element on the spec in chrome |
| 22:19 | <jonathanj> | i would have expected html5lib to be able to parse xhtml, or is this an lxml issue? |
| 22:19 | <Hixie> | jonathanj: html5lib is for parsing html, not xml :-) |
| 22:21 | <cabanier> | hixie: not sure if you saw my earlier message but I noticed that not all images from the Canvas2D spec are checked in with SVN. |
| 22:21 | <Hixie> | cabanier: yeah i fixed it |
| 22:21 | <cabanier> | hixie: great! |
| 22:22 | <Hixie> | (i always forget to do "svn add") |
| 22:22 | <cabanier> | :-) |
| 22:55 | <jonathanj> | Hixie: thanks, that's actually good advice |
| 22:55 | <jonathanj> | even if i didn't think that 30 minutes ago |
| 22:56 | <Hixie> | heh |