CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
Yesterday Hixie closed several of the Web Sockets bugs mentioned in the e-mail below and he updated others. I think this now provides a basis to determine if we have consensus to publish a Candidate Recommendation. As such, this is a Call for Consensus to publish a Candidate Recommendation of Web Sockets. I propose the CR be based on the May 24 LC [1] plus include: 1. The editorial patch for 17224 [2] 2. The patch [3] to remove the TreatNonCallableAsNull qualifier for some attributes. If anyone considers this change as substantive, please speak up. Cameron - what's your opinion on this? Additionally: * 12510 - as Hixie indicated in the bug, if anyone is willing to create a patch, please contact Hixie privately and please let me know of your intent * 15829 - the CR will include a fix for this as was done for the LC * 16927 - the CR will include a fix for this as was done for the LC * Other bugs to remain open for v.next: 15209, 15210, 17073, 17264, 17685 * The CR's exit criteria be identical to the December 2011 CR. This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs Positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is July 18 and all comments should be sent to public-webapps at w3.org. -Thanks, AB [1] http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.269;r2=1.270;f=h [2] http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.268;r2=1.269;f=h [3] http://www.w3.org/TR/2012/WD-websockets-20120524/ Original Message Subject: [websockets] Seeking comments on moving back to CR; deadline June 28 Resent-Date:Thu, 21 Jun 2012 14:29:06 + Resent-From:public-webapps@w3.org Date: Thu, 21 Jun 2012 10:28:31 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org Hi All, I created a tracking document for the two comments and five bugs that were submitted against the 24 May LCWD of Web Sockets (or in the approximate time frame of that publication): http://www.w3.org/2008/webapps/wiki/Websockets-Comments-LC-24May2012. Below is my take on these bugs and comments. It would be good to get this spec back to CR and hence closer toward the IP commitments that will only be final when the spec reaches Recommendation. Bugs: * 17073 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17073 - marked as an Enhancement; don't include in the v1 CR * 17224 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17224 - this looks like an Editorial bug to me as I stated in the bug. Assuming there is consensus the text should be unsolicited pongs, if Hixie can't fix this before the v1 CR copy is created, I'll make this change in the v1 CR. * 17262 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262 - Jonas' view as expressed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17262#c13 seems reasonable so I propose closing this with a resolution of WorksForMe. * 17263 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17263 - send(ArrayBuffer), which was included in the December 2011 CR, has been implemented and presumably must be supported by some browsers (e.g. bc/legacy reasons). As such, it seems reasonable to fix this bug and perhaps we could argue a new LCWD is not needed since it has already been implemented. * 17264 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264 - this bug appears to be a rehash of bug 13104 which was Fixed in October 2011 so I propose closing this with a resolution of Duplicate. Comments: * LC-1 http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0807.html - The 28-May-2012 reply by Takeshi Yoshino notes this is a Chrome bug and not a spec bug. The 1-June-2012 reply by Simon Pieters indicates the Protocol spec needs to be updated. As such, I don't think any changes are needed for v1 of the spec. * LC-2 http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0880.html - This is an editorial bug and is already captured in Bug 12510. Ideally, this bug would be fixed before the v1 CR branch is created. However, if Hixie can't fix it before then and if no one else creates an acceptable patch for Hixie, I don't support blocking the v1 CR for this. Please send all comments by June 28. -Thanks, AB
RfC: Content Security Policy 1.0 Last Call; deadline Aug 24
WebApps has been asked to review the July 10 LCWD of WebAppSec's Content Security Policy 1.0 spec http://www.w3.org/TR/2012/WD-CSP-20120710/. Individual WG members are encouraged to provide individual feedback directly to the Web Perf WG. If you have comments, please send them to the following list by August 24: public-webapp...@w3.org http://lists.w3.org/Archives/Public/public-webappsec/ If anyone in WebApps wants to propose an official WG response, please do so ASAP, in reply to this email so the Working Group can discuss it. -Thanks, AB
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On 2012-07-11 15:11, Arthur Barstow wrote: Yesterday Hixie closed several of the Web Sockets bugs mentioned in the e-mail below and he updated others. I think this now provides a basis to determine if we have consensus to publish a Candidate Recommendation. As such, this is a Call for Consensus to publish a Candidate Recommendation of Web Sockets. I propose the CR be based on the May 24 LC [1] plus include: 1. The editorial patch for 17224 [2] 2. The patch [3] to remove the TreatNonCallableAsNull qualifier for some attributes. If anyone considers this change as substantive, please speak up. Cameron - what's your opinion on this? Additionally: * 12510 - as Hixie indicated in the bug, if anyone is willing to create a patch, please contact Hixie privately and please let me know of your intent ... I'll re-state that the current spec is under defined, and should not be published. As far as I can tell, the W3C team will have to tune some parts of the spec anyway, so why not also insert the missing links? (If the answer to that is: too much work then why do you consider that it's not a problem for the *audience* of the spec?) Best regards, Julian
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
Art wrote: As such, this is a Call for Consensus to publish a Candidate Recommendation of Web Sockets. Ship it! :) Ted
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On Wed, Jul 11, 2012 at 10:52 AM, Edward O'Connor eocon...@apple.comwrote: Art wrote: As such, this is a Call for Consensus to publish a Candidate Recommendation of Web Sockets. Ship it! :) +1
Re: [UndoManager] Re-introduce DOMTransaction interface?
Another thing to consider if we add DOMTransaction back in is that you now
need to specifiy what happens in more cases, e.g.:
-call transact on the same DOMTransaction twice
-call transact on a DOMTransaction then modify undo/redo listeners
These are solvable problems, but are just more complicated than using a
dictionary. I really see no point in adding DOMTransaction back. If you
want, you could make transact just take the arguments you want
DOMTransaction to take. Then of course, you end up in the case of needing a
bunch of optional arguments due to automatic vs. manual transactions, which
leads us back to using a dictionary.
An alternative interface I'd be happy with would be transact(String label,
Dictionary optionalArguments) since label is always required.
On Mon, Jul 9, 2012 at 10:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jul 9, 2012 at 9:52 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Jul 9, 2012 at 9:41 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jul 9, 2012 at 7:30 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Fri, Jul 6, 2012 at 12:09 PM, Ryosuke Niwa rn...@webkit.org
wrote:
Okay, it appears to be a miscommunication of terminology here. What I
meant
is DOM APIs in your definition. As Adam said, API fashions come and
go.
We
should be making new DOM APIs consistent with existing DOM APIs.
While API fashions do change, this doesn't appear to be a fashion. A
ton of popular libraries have been doing this for years, and it
doesn't seem to be flagging. Language-supported variations of this
pattern exist in other popular languages as well, such as Python.
Yeah, and Python does all other things I don't like e.g. using
indentation
instead of { } or begin/end.
Irrelevant to the discussion. Nobody's suggesting to adopt other
Pythonisms. I was just pointing to Python to support my assertion
that this is now a very popular pattern, not a transient fashion.
And I was saying that just because Python does it, it doesn't mean it's
desirable nor does it support your assertion.
Also, we're not forced to use named arguments
in Python. If we have a function like:
def transact(execute, undo, redo):
~~
you can call it as either:
transact(execute=a, undo=b, redo=c)
or
transact(a, b, c)
Yes, and it would be wonderful if JS had similar support so that we
could easily accommodate both patterns. It doesn't, and so we have to
choose one or the other.
Yes, but that should be addressed in TC39.
On the other hand, other popular programming languages like Java and C++
don't support named arguments.
Of course. They, like the DOM APIs, are old (hell, C++ is older than
you or me). Evolution happens.
I personally find named arguments in various library functions
annoying
especially when there are only few arguments. e.g.
parent.appendChild({child: node}); would be silly.
Come on, Ryosuke, don't strawman. Obviously when there's only a
single argument, there's no concerns about remembering the order. Two
args are often fine, but PHP shows us quite clearly that's it's easy
to screw that up and make it hard to remember (see the persistent
confusion in PHP search functions about whether the needle or haystack
comes first). Three and up, you should definitely use named args
unless there's a strong logical order. (For example, an API taking a
source and dest rectangle can reasonably support 8 ordered args,
because x,y,w,h and source,dest are strong logical orders.)
In our case, there's a clear logical ordering: execute, undo, redo.
I don't get it. That doesn't seem like a logical ordering to me.
It is because that's the order in which these functions can be called. You
can't call redo before calling undo, and you can't call undo before execute.
By that I mean, there's no clear reason for me to assume, having not used
this API before, that they should appear in that order, nor is there
an existing well-established pattern across many other APIs that they
appear in that particular order.
Undo appearing before Redo is a very well established pattern:
http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUndoManager_Class/Reference/Reference.html
Having execute is somewhat odd because there are no other frameworks in
which such a function appears in an object that represents undo/redo.
That's another reason I like Yuval's proposal over the current design.
- Ryosuke
Re: [UndoManager] Re-introduce DOMTransaction interface?
On Wed, Jul 11, 2012 at 10:36 AM, Ojan Vafai o...@chromium.org wrote: Another thing to consider if we add DOMTransaction back in is that you now need to specifiy what happens in more cases, e.g.: -call transact on the same DOMTransaction twice -call transact on a DOMTransaction then modify undo/redo listeners You mean execute? Assuming that, the first one is a good point. We have the second problem already with the dictionary interface because scripts can add and or remove execute/executeAutomatic/undo/redo from the dictionary within those functions or between transact/undo/redo. These are solvable problems, but are just more complicated than using a dictionary. I really see no point in adding DOMTransaction back. The point of adding them back is so that undo/redo are implemented as events like any other DOM API we have. If you want, you could make transact just take the arguments you want DOMTransaction to take. Then of course, you end up in the case of needing a bunch of optional arguments due to automatic vs. manual transactions, which leads us back to using a dictionary. An alternative interface I'd be happy with would be transact(String label, Dictionary optionalArguments) since label is always required. Well, label isn't always required; e.g. when a transaction is merged with previous transaction. - Ryosuke
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On 2012-07-11 20:25, Julian Reschke wrote:
On 2012-07-11 15:44, Julian Reschke wrote:
On 2012-07-11 15:11, Arthur Barstow wrote:
Yesterday Hixie closed several of the Web Sockets bugs mentioned in the
e-mail below and he updated others. I think this now provides a basis to
determine if we have consensus to publish a Candidate Recommendation. As
such, this is a Call for Consensus to publish a Candidate Recommendation
of Web Sockets.
I propose the CR be based on the May 24 LC [1] plus include:
1. The editorial patch for 17224 [2]
2. The patch [3] to remove the TreatNonCallableAsNull qualifier for some
attributes. If anyone considers this change as substantive, please speak
up. Cameron - what's your opinion on this?
Additionally:
* 12510 - as Hixie indicated in the bug, if anyone is willing to create
a patch, please contact Hixie privately and please let me know of your
intent
...
I'll re-state that the current spec is under defined, and should not be
published.
As far as I can tell, the W3C team will have to tune some parts of the
spec anyway, so why not also insert the missing links?
(If the answer to that is: too much work then why do you consider that
it's not a problem for the *audience* of the spec?)
...
OK; the amount of work is ~45 minutes (and probably can be automated for
future publication cycles).
See attachments; an edited version of the current editor's draft, and
the diffs.
...
..and the diff was reversed; new version attached.
--- wsapi.html 2012-07-10 22:38:35.0 +0100
+++ ws.html 2012-07-11 19:20:05.712293700 +0100
@@ -507,7 +507,7 @@
h2 id=the-websocket-interfacespan class=secno4 /spanThe codea
href=#websocketWebSocket/a/code interface/h2
pre class=idl[a href=#dom-websocket
title=dom-WebSocketConstructor/a(DOMString url, optional (DOMString or
DOMString[]) protocols)]
-interface dfn id=websocketWebSocket/dfn : spanEventTarget/span {
+interface dfn id=websocketWebSocket/dfn : a
href=http://dev.w3.org/html5/spec/infrastructure.html#eventtarget;EventTarget/a
{
readonly attribute DOMString a href=#dom-websocket-url
title=dom-WebSocket-urlurl/a;
// ready state
@@ -519,23 +519,23 @@
readonly attribute unsigned long a href=#dom-websocket-bufferedamount
title=dom-WebSocket-bufferedAmountbufferedAmount/a;
// networking
- attribute spanEventHandler/span a
href=#handler-websocket-onopen title=handler-WebSocket-onopenonopen/a;
- attribute spanEventHandler/span a
href=#handler-websocket-onerror title=handler-WebSocket-onerroronerror/a;
- attribute spanEventHandler/span a
href=#handler-websocket-onclose title=handler-WebSocket-oncloseonclose/a;
+ attribute a
href=http://dev.w3.org/html5/spec/webappapis.html#eventhandler;EventHandler/a
a href=#handler-websocket-onopen
title=handler-WebSocket-onopenonopen/a;
+ attribute a
href=http://dev.w3.org/html5/spec/webappapis.html#eventhandler;EventHandler/a
a href=#handler-websocket-onerror
title=handler-WebSocket-onerroronerror/a;
+ attribute a
href=http://dev.w3.org/html5/spec/webappapis.html#eventhandler;EventHandler/a
a href=#handler-websocket-onclose
title=handler-WebSocket-oncloseonclose/a;
readonly attribute DOMString a href=#dom-websocket-extensions
title=dom-WebSocket-extensionsextensions/a;
readonly attribute DOMString a href=#dom-websocket-protocol
title=dom-WebSocket-protocolprotocol/a;
void a href=#dom-websocket-close
title=dom-WebSocket-closeclose/a([Clamp] optional unsigned short code,
optional DOMString reason);
// messaging
- attribute spanEventHandler/span a
href=#handler-websocket-onmessage
title=handler-WebSocket-onmessageonmessage/a;
+ attribute a
href=http://dev.w3.org/html5/spec/webappapis.html#eventhandler;EventHandler/a
a href=#handler-websocket-onmessage
title=handler-WebSocket-onmessageonmessage/a;
attribute DOMString a href=#dom-websocket-binarytype
title=dom-WebSocket-binaryTypebinaryType/a;
void a href=#dom-websocket-send
title=dom-WebSocket-sendsend/a(DOMString data);
void a href=#dom-websocket-send
title=dom-WebSocket-sendsend/a(spanArrayBufferView/span data);
- void a href=#dom-websocket-send
title=dom-WebSocket-sendsend/a(spanBlob/span data);
+ void a href=#dom-websocket-send title=dom-WebSocket-sendsend/a(a
href=http://dev.w3.org/html5/spec/infrastructure.html#blob;Blob/a data);
};/pre
pThe dfn id=dom-websocket title=dom-WebSocketcodeWebSocket(var
title=url/var, var title=protocols/var)/code/dfn
- constructor takes one or two arguments. The first argument, var
title=url/var, specifies the spanURL/span to which to
+ constructor takes one or two arguments. The first argument, var
title=url/var, specifies the a
href=http://dev.w3.org/html5/spec/urls.html#url;URL/a to which to
connect. The second, var title=protocols/var, if present, is
either a string or an array of strings. If it is a string, it is
equivalent to
Re: [File API] File behavior under modification
Glenn: On May 21, 2012, at 9:44 PM, Glenn Maynard wrote: On Mon, May 21, 2012 at 6:05 PM, Eric U er...@google.com wrote: According to the latest editor's draft [1], a File object must always return an accurate lastModifiedDate if at all possible. On getting, if user agents can make this information available, this MUST return a new Date[HTML] object initialized to the last modified date of the file; otherwise, this MUST return null. However, if the underlying file has been modified since the creation of the File, reads processed on the File must throw exceptions or fire error events. ...if the file has been modified on disk since the File object reference is created, user agents MUST throw a NotReadableError... (I wish this spec would remove the screaming MUSTs; HTML doesn't do this anymore, and it's so much easier to read.) WHAT? Heh :) Point well taken. I've muted the musts. These seem somewhat contradictory...you can always look at the modification time and see that it's changed, but if you try to read it after a change, it blows up. The non-normative text about security concerns makes me think that perhaps both types of operations should fail if the file has changed [... guarding against modifications of files on disk after a selection has taken place]. That may not be necessary, but if it's not, I think we should call it out in non-normative text that explains why you can read the mod time and not the data. I think lastModifiedDate should never change. It should be the mtime of the version of the file that the File represents a snapshot of. This avoids synchronicity issues: reading the value twice in a row in the same script should never give a different value or throw the second time but not the first, because that exposes the multithreading nature of the filesystem. It also avoids implying that this attribute needs to perform synchronous I/O in the middle of script execution to check the file's current timestamp, which of course should never happen. If we want to allow querying whether the mtime of a file has changed, it should be done with a new asynchronous API. I'm not sure that's needed, though, since you can always just read one byte from the file; if it fails, the file has changed. I agree that making snapshotting clearer might be a good idea. It is true that reading size and lastModifiedDate are synchronous, but this seemed a small trade-off compared to data reads. My instinct is that an asynchronous API for mtime is overkill. (While I'm thining about it, does lastModifiedDate really need to be nullable? Systems without file timestamps are so rare that it's probably better to require them to fabricate a date, so we don't introduce bugs into people's code for rare cases.) What's the main problem with it being nullable? A fabricated date seems strange, but instead of being nullable we could spec what the fabricated date is. I'm just not totally sure what the pros and cons are here. This came up in https://bugs.webkit.org/show_bug.cgi?id=86811; I believe WebKit is currently noncompliant with this part of the spec, and we were debating the correct behavior. Currently WebKit delays grabbing the modification time of the file until it's been referenced by a read or slice(), so it won't notice modifications that happen between selection and read. This sounds very wrong to me. If I open a File in a page (eg. select it with an input), the model is that I'm giving it access to the file as it was at the time I dragged it in. If the snapshot is delayed until the first read, the page will be able to see changes made later, as long as it doesn't touch the file immediately. That breaks the whole security model. Strong +1. Also, slice() is a synchronous API, so it should never cause blocking file I/O. That's fundamental to the API. That was done because the slice creates a File object reference, but in my reading creating the File referring to the file should be the time of the snapshot, not creating a Blob referring to a File. FWIW, agreed. Can you log a bug so that I can provide guidance for this in spec? -- A*
[Bug 17746] New: Specify Blob snapshots more robustly
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17746 Summary: Specify Blob snapshots more robustly Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: File API AssignedTo: a...@mozilla.com ReportedBy: a...@mozilla.com QAContact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org, gl...@zewt.org - The access restrictions applied to File also need to be clearly applied to Blobs created with slice(). - modified on disk since the File object reference is created seems incorrect. If you structured clone a File (eg. postMessage), you create a new File object. That shouldn't refresh the snapshot; you should still only be able to access the file as it was when you received the *original* File. I'd suggest defining this more precisely, and at the level of Blob. Here's an attempt: - In section 6, add: Each Blob has a snapshot state, which is initially set to the state of the underlying storage. Note: this value is preserved through structured clone. - Also in section 6, add: If, at the time of any read operation on the Blob, the state of the underlying storage containing the Blob is not equal to snapshot state, the read must fail with a NotReadableError. - In 6.3.2. The slice method, add: Let the snapshot state of A be the snapshot state of O. (This means the snapshot state follows through slices.) - In 7.1, remove For synchronous reads The requirement to fail is now defined by section 6, and the way it fails (passing on the NotReadableError or an error event) should be defined by the associated read operation. This stores a conceptual snapshot of the underlying storage at the time the Blob (or File) is created. The snapshot state is purely conceptual, representing the logical underlying snapshot that the Blob represents. If it represents a file on disk, and the file changes (or is deleted), it has a new snapshot state. This approach puts the requirement at the Blob level. For Blobs whose underlying storage can never be modified (regular, old-fashioned blobs), it has no effect, since the snapshot state never changes. The snapshot is made when the a Blob (or File) is constructed, except for slice() and structured clone, which copy the source object's state. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [File API] File behavior under modification
Glenn, On May 22, 2012, at 11:48 AM, Glenn Maynard wrote: On Tue, May 22, 2012 at 1:41 AM, Kinuko Yasuda kin...@google.com wrote: In my understanding WebKit's behavior is querying the metadata / reading the content as lazy as possible, partly because the spec was/is ambiguous (especially about when the file metadata should be captured) and also we didn't want to break existing Web applications. But the synchronicity of the current .size, .modificationTime and .slice() implementation has been a big headache and I'm all happy if we can make the behavior clearer. The whole point of the Blob API is to never, ever do file I/O synchronously in the UI thread. (I think the read into memory at the time a read operation is initiated bit is what's confusing things. I don't think it was intended to mean take the snapshot at the first read operation, but that's what it sounds like.) Some other issues: snip / - The access restrictions applied to File also need to be clearly applied to Blobs created with slice(). - modified on disk since the File object reference is created seems incorrect. If you structured clone a File (eg. postMessage), you create a new File object. That shouldn't refresh the snapshot; you should still only be able to access the file as it was when you received the *original* File. I'd suggest defining this more precisely, and at the level of Blob. Here's an attempt: - In section 6, add: Each Blob has a snapshot state, which is initially set to the state of the underlying storage. Note: this value is preserved through structured clone. - Also in section 6, add: If, at the time of any read operation on the Blob, the state of the underlying storage containing the Blob is not equal to snapshot state, the read must fail with a NotReadableError. - In 6.3.2. The slice method, add: Let the snapshot state of A be the snapshot state of O. (This means the snapshot state follows through slices.) - In 7.1, remove For synchronous reads The requirement to fail is now defined by section 6, and the way it fails (passing on the NotReadableError or an error event) should be defined by the associated read operation. This stores a conceptual snapshot of the underlying storage at the time the Blob (or File) is created. The snapshot state is purely conceptual, representing the logical underlying snapshot that the Blob represents. If it represents a file on disk, and the file changes (or is deleted), it has a new snapshot state. This approach puts the requirement at the Blob level. For Blobs whose underlying storage can never be modified (regular, old-fashioned blobs), it has no effect, since the snapshot state never changes. The snapshot is made when the a Blob (or File) is constructed, except for slice() and structured clone, which copy the source object's state. These are really solid proposals, and I've filed Bug 17746 to keep track of this. https://www.w3.org/Bugs/Public/show_bug.cgi?id=17746 -- A* -- Glenn Maynard
Re: [File API] File behavior under modification
On May 23, 2012, at 9:58 AM, Glenn Maynard wrote: On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda kin...@chromium.org wrote: Just to make sure, I assume 'the underlying storage' includes memory. Right. For simple Blobs without a mutable backing store, all of this essentially optimizes away. We should also make it clear whether .size and .lastModifiedDate should return live state or should just returning the same constant values. (I assume the latter) It would be the values at the time of the snapshot state. (I doubt it was ever actually intended that lastModifiedDate always return the file's latest mtime. We'll find out when one of the editors gets around to this thread...) I think the ideal behavior is that it reflects values at snapshot state, but that reads if snapshot state has modified fail. -- A*
Re: [File API] Blob URI creation
On May 30, 2012, at 6:48 PM, Glenn Maynard wrote:
On your main question, I've had the same thought in the past--a url
property on Blob which simply creates a new auto-revoking blob URL. I didn't
bring it up since I'm not sure if creating a URL for a blob is actually
something you do so often that it's worth having a shortcut. If so, a
function is probably better than a property--more future-proof, and it'd be
unusual on the platform to have a property that returns a different value
every time you read it.
On Wed, May 30, 2012 at 1:50 PM, Rich Tibbett ri...@opera.com wrote:
Yes, this might be a better solution. I was working on what was available in
the editor's draft and looking for a way to remove the need to ever call
revokeObjectUrl.
This is part of what's wrong with oneTimeOnly--it *doesn't* actually
completely remove the need to call revokeObjectUrl. For example:
function f(blob) {
var url = URL.createObjectURL(blob, {oneTimeOnly: true});
if(showImage)
img.src = url;
else
URL.revokeObjectURL(url);
}
Without the revoke case, the URL (and so the whole blob) is leaked as it's
never actually used. autoRevoke doesn't have this problem.
Arun/Jonas: Can we hide this feature in the spec before more people implement
it, or at least tag it with not ready for implementations or something?
I'll do one better, and introduce autoRevoke semantics:
http://www.w3.org/TR/2012/WD-FileAPI-20120712/#creating-revoking
By default, this does not need a corresponding revokeObjectURL() call. In
order for Blob URLs to persist past a stable state (for that unit of script)
createObjectURL has to be invoked with autoRevoke set to false.
That is, you shouldn't ever have to pass a Blob URI obtained via Blob.getURL
through revokeObjectUrl because it assumes some auto-revocation behavior.
Using microtasks to release at the next stable state does seem ok as long as
developers have a very good understanding of when a Blob URI will be
implicitly revoked. Saying that you can use a Blob URI exactly once, as per
onetimeonly could still end up being easier to understand though.
(s/microtasks/stable states/; they're not quite the same)
It's actually a bit hard to understand (or easy to misunderstand), since
there's no clear concept of using a URL. For example, if you start two
XHR's on the same URL one after the other in the same script, the order in
which the fetches actually begin is undefined (they happen in different task
queues), so which would succeed is undefined. (Some work would also be
needed here for the autoRevoke approach, but it's much simpler.)
autoRevoke is pretty simple from the user's perspective: the URL is revoked
when your script returns to the browser.
In fact, I think this addresses the lion's share of use cases, and if a
developer wants to explicitly create longer lasting Blob URLs, they have that
option (just not by default).
-- A*
Re: [UndoManager] Re-introduce DOMTransaction interface?
On Wed, Jul 11, 2012 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jul 11, 2012 at 10:36 AM, Ojan Vafai o...@chromium.org wrote: Another thing to consider if we add DOMTransaction back in is that you now need to specifiy what happens in more cases, e.g.: -call transact on the same DOMTransaction twice -call transact on a DOMTransaction then modify undo/redo listeners You mean execute? Assuming that, the first one is a good point. We have the second problem already with the dictionary interface because scripts can add and or remove execute/executeAutomatic/undo/redo from the dictionary within those functions or between transact/undo/redo. We don't have this problem with the dictionary interface because we don't store the actual dictionary. We take the dictionary and construct a C++ (DOMTransaction?) entry into the undomanager. So, if you reuse the same dictionary, you get a new C++ object stored for each transact call. If you modify the dictionary after the transact call, it does not affect the stored C++ object. These are solvable problems, but are just more complicated than using a dictionary. I really see no point in adding DOMTransaction back. The point of adding them back is so that undo/redo are implemented as events like any other DOM API we have. I don't see the benefit here. I don't think this is a more author-friendly API. If you want, you could make transact just take the arguments you want DOMTransaction to take. Then of course, you end up in the case of needing a bunch of optional arguments due to automatic vs. manual transactions, which leads us back to using a dictionary. An alternative interface I'd be happy with would be transact(String label, Dictionary optionalArguments) since label is always required. Well, label isn't always required; e.g. when a transaction is merged with previous transaction. Doesn't that make DOMTransaction(label, execute) a problem? I suppose it could be DOMTransaction(execute, optional label). Speaking of merge, why is it on transact and not on the transaction dictionary. The latter makes more sense to me. Ojan
Re: [UndoManager] Re-introduce DOMTransaction interface?
On Wed, Jul 11, 2012 at 3:12 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jul 11, 2012 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 10:36 AM, Ojan Vafai o...@chromium.org wrote:
Another thing to consider if we add DOMTransaction back in is that you
now need to specifiy what happens in more cases, e.g.:
-call transact on the same DOMTransaction twice
-call transact on a DOMTransaction then modify undo/redo listeners
You mean execute? Assuming that, the first one is a good point. We have
the second problem already with the dictionary interface because scripts
can add and or remove execute/executeAutomatic/undo/redo from the
dictionary within those functions or between transact/undo/redo.
We don't have this problem with the dictionary interface because we don't
store the actual dictionary. We take the dictionary and construct a C++
(DOMTransaction?) entry into the undomanager. So, if you reuse the same
dictionary, you get a new C++ object stored for each transact call. If you
modify the dictionary after the transact call, it does not affect the
stored C++ object.
I don't follow. Your second point is that it's ambiguous as to what should
happen when undo/redo event listeners are modified. I'm saying that the
same ambiguity rises when the script modifies undo/redo properties of the
pure JS object that implements DOMTransaction because we don't store
undo/redo properties in a separate C++ (or whatever language you're
implementing UA with) object inside transact().
By the way, let us refrain from using the word dictionary here because
there is a specific object named Dictionary in WebIDL and multiple folks on
IRC have told me that our use of the term dictionary is confusing. For
further clarify, the dictionary in the current specification is an user
object implementing the DOMTransaction callback interface as defined in:
http://www.w3.org/TR/WebIDL/#es-user-objects It can't be a Dictionary
because execute, executeAutomatic, undo, and redo need to be called on the
object; e.g. if we had t = {execute: function () { this.undo = function ()
{ ~}; }}}, then execute will change the undo IDL attribute of t.
These are solvable problems, but are just more complicated than using a
dictionary. I really see no point in adding DOMTransaction back.
The point of adding them back is so that undo/redo are implemented as
events like any other DOM API we have.
I don't see the benefit here. I don't think this is a more author-friendly
API.
Consistency.
If you want, you could make transact just take the arguments you want
DOMTransaction to take. Then of course, you end up in the case of needing a
bunch of optional arguments due to automatic vs. manual transactions, which
leads us back to using a dictionary.
An alternative interface I'd be happy with would be transact(String
label, Dictionary optionalArguments) since label is always required.
Well, label isn't always required; e.g. when a transaction is merged with
previous transaction.
Doesn't that make DOMTransaction(label, execute) a problem? I suppose it
could be DOMTransaction(execute, optional label).
Yes, DOMTransaction needs to take execute first.
Speaking of merge, why is it on transact and not on the transaction
dictionary. The latter makes more sense to me.
Because of the fact DOMTransaction had been a user object. It would be
awfully confusing if the script could override the value of merge. If we
had re-introduced the DOMTransaction interface, then we can make merge a
readonly attribute on the object.
- Ryosuke
Re: [UndoManager] Re-introduce DOMTransaction interface?
On Wed, Jul 11, 2012 at 3:23 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 3:12 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jul 11, 2012 at 11:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 10:36 AM, Ojan Vafai o...@chromium.org wrote:
Another thing to consider if we add DOMTransaction back in is that you
now need to specifiy what happens in more cases, e.g.:
-call transact on the same DOMTransaction twice
-call transact on a DOMTransaction then modify undo/redo listeners
You mean execute? Assuming that, the first one is a good point. We have
the second problem already with the dictionary interface because scripts
can add and or remove execute/executeAutomatic/undo/redo from the
dictionary within those functions or between transact/undo/redo.
We don't have this problem with the dictionary interface because we don't
store the actual dictionary. We take the dictionary and construct a C++
(DOMTransaction?) entry into the undomanager. So, if you reuse the same
dictionary, you get a new C++ object stored for each transact call. If you
modify the dictionary after the transact call, it does not affect the
stored C++ object.
I don't follow. Your second point is that it's ambiguous as to what should
happen when undo/redo event listeners are modified. I'm saying that the
same ambiguity rises when the script modifies undo/redo properties of the
pure JS object that implements DOMTransaction because we don't store
undo/redo properties in a separate C++ (or whatever language you're
implementing UA with) object inside transact().
By the way, let us refrain from using the word dictionary here because
there is a specific object named Dictionary in WebIDL and multiple folks on
IRC have told me that our use of the term dictionary is confusing. For
further clarify, the dictionary in the current specification is an user
object implementing the DOMTransaction callback interface as defined in:
http://www.w3.org/TR/WebIDL/#es-user-objects It can't be a Dictionary
because execute, executeAutomatic, undo, and redo need to be called on the
object; e.g. if we had t = {execute: function () { this.undo = function ()
{ ~}; }}}, then execute will change the undo IDL attribute of t.
I was specifically talking about WebIDL Dictionaries. In which case,
this.undo would set the undo property on the window. Why would you want to
be able to set the undo function from the execut function? My whole point
has been that we should not keep the actual object.
These are solvable problems, but are just more complicated than using a
dictionary. I really see no point in adding DOMTransaction back.
The point of adding them back is so that undo/redo are implemented as
events like any other DOM API we have.
I don't see the benefit here. I don't think this is a more
author-friendly API.
Consistency.
It's more consistent in some ways and less in others. There aren't many
instances of constructing an object and passing it to a method. There are
increasingly many methods that take Dictionaries in. There are many methods
that take pure callbacks. You have to squint to call this more consistent
IMO.
Speaking of merge, why is it on transact and not on the transaction
dictionary. The latter makes more sense to me.
Because of the fact DOMTransaction had been a user object. It would be
awfully confusing if the script could override the value of merge. If we
had re-introduced the DOMTransaction interface, then we can make merge a
readonly attribute on the object.
To clarify my position here, I think transact should take in a Dictionary.
Then the useragent converts that into a DOMTransaction and stores it in the
UndoManager's history. So, item would return a DOMTransaction. In that
case, merge could be a value in the Dictionary and readonly on the
DOMTransaction.
The only part we disagree about I think is whether transact should take a
Dictionary or a DOMTransaction. Storing a DOMTransaction and returning it
from item, seems reasonable to me.
Ojan
Re: [File API] File behavior under modification
Agreed. On Wed, Jul 11, 2012 at 1:02 PM, Arun Ranganathan aranganat...@mozilla.com wrote: On May 23, 2012, at 9:58 AM, Glenn Maynard wrote: On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda kin...@chromium.org wrote: Just to make sure, I assume 'the underlying storage' includes memory. Right. For simple Blobs without a mutable backing store, all of this essentially optimizes away. We should also make it clear whether .size and .lastModifiedDate should return live state or should just returning the same constant values. (I assume the latter) It would be the values at the time of the snapshot state. (I doubt it was ever actually intended that lastModifiedDate always return the file's latest mtime. We'll find out when one of the editors gets around to this thread...) I think the ideal behavior is that it reflects values at snapshot state, but that reads if snapshot state has modified fail. -- A*
Re: [UndoManager] Re-introduce DOMTransaction interface?
On Wed, Jul 11, 2012 at 3:35 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jul 11, 2012 at 3:23 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 3:12 PM, Ojan Vafai o...@chromium.org wrote:
We don't have this problem with the dictionary interface because we
don't store the actual dictionary. We take the dictionary and construct a
C++ (DOMTransaction?) entry into the undomanager. So, if you reuse the same
dictionary, you get a new C++ object stored for each transact call. If you
modify the dictionary after the transact call, it does not affect the
stored C++ object.
I don't follow. Your second point is that it's ambiguous as to what
should happen when undo/redo event listeners are modified. I'm saying that
the same ambiguity rises when the script modifies undo/redo properties of
the pure JS object that implements DOMTransaction because we don't store
undo/redo properties in a separate C++ (or whatever language you're
implementing UA with) object inside transact().
By the way, let us refrain from using the word dictionary here because
there is a specific object named Dictionary in WebIDL and multiple folks on
IRC have told me that our use of the term dictionary is confusing. For
further clarify, the dictionary in the current specification is an user
object implementing the DOMTransaction callback interface as defined in:
http://www.w3.org/TR/WebIDL/#es-user-objects It can't be a Dictionary
because execute, executeAutomatic, undo, and redo need to be called on the
object; e.g. if we had t = {execute: function () { this.undo = function ()
{ ~}; }}}, then execute will change the undo IDL attribute of t.
I was specifically talking about WebIDL Dictionaries. In which case,
this.undo would set the undo property on the window. Why would you want to
be able to set the undo function from the execut function? My whole point
has been that we should not keep the actual object.
Oh, then you're proposing something different here. There is a use case for
being able to add custom properties (for extra information used by library,
etc...) and store that in the undo manager. If we had used Dictionary for,
say, the constructor of DOMTransaction, then you'd have to add those
properties after creating DOMTransaction. If you're proposing to use
Dictionary for transact() so that we don't keep any objects, then that just
doesn't work.
Speaking of merge, why is it on transact and not on the transaction
dictionary. The latter makes more sense to me.
Because of the fact DOMTransaction had been a user object. It would be
awfully confusing if the script could override the value of merge. If we
had re-introduced the DOMTransaction interface, then we can make merge a
readonly attribute on the object.
To clarify my position here, I think transact should take in a Dictionary.
Then the useragent converts that into a DOMTransaction and stores it in the
UndoManager's history. So, item would return a DOMTransaction. In that
case, merge could be a value in the Dictionary and readonly on the
DOMTransaction.
So one big use pattern we're predicting is something along the line of:
undoManager.transact(transactionFactory(~~));
where transactionFactory can create a custom DOM transaction object. Now
all properties set on the object returned by transactionFactory will be
lost when execute/executeAutomatic/undo/redo are called in your proposal,
and that's very counter intuitive and weird in my opinion.
- Ryosuke
Re: [UndoManager] Re-introduce DOMTransaction interface?
On Wed, Jul 11, 2012 at 3:47 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 3:35 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Jul 11, 2012 at 3:23 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 3:12 PM, Ojan Vafai o...@chromium.org wrote:
We don't have this problem with the dictionary interface because we
don't store the actual dictionary. We take the dictionary and construct a
C++ (DOMTransaction?) entry into the undomanager. So, if you reuse the same
dictionary, you get a new C++ object stored for each transact call. If you
modify the dictionary after the transact call, it does not affect the
stored C++ object.
I don't follow. Your second point is that it's ambiguous as to what
should happen when undo/redo event listeners are modified. I'm saying that
the same ambiguity rises when the script modifies undo/redo properties of
the pure JS object that implements DOMTransaction because we don't store
undo/redo properties in a separate C++ (or whatever language you're
implementing UA with) object inside transact().
By the way, let us refrain from using the word dictionary here because
there is a specific object named Dictionary in WebIDL and multiple folks on
IRC have told me that our use of the term dictionary is confusing. For
further clarify, the dictionary in the current specification is an user
object implementing the DOMTransaction callback interface as defined in:
http://www.w3.org/TR/WebIDL/#es-user-objects It can't be a Dictionary
because execute, executeAutomatic, undo, and redo need to be called on the
object; e.g. if we had t = {execute: function () { this.undo = function ()
{ ~}; }}}, then execute will change the undo IDL attribute of t.
I was specifically talking about WebIDL Dictionaries. In which case,
this.undo would set the undo property on the window. Why would you want to
be able to set the undo function from the execut function? My whole point
has been that we should not keep the actual object.
Oh, then you're proposing something different here. There is a use case
for being able to add custom properties (for extra information used by
library, etc...) and store that in the undo manager. If we had used
Dictionary for, say, the constructor of DOMTransaction, then you'd have to
add those properties after creating DOMTransaction. If you're proposing to
use Dictionary for transact() so that we don't keep any objects, then that
just doesn't work.
What are the cases where you need this? Closures over your
execute/undo/redo methods seem to me like it would address this use-case
fine.
Speaking of merge, why is it on transact and not on the transaction
dictionary. The latter makes more sense to me.
Because of the fact DOMTransaction had been a user object. It would be
awfully confusing if the script could override the value of merge. If we
had re-introduced the DOMTransaction interface, then we can make merge a
readonly attribute on the object.
To clarify my position here, I think transact should take in a
Dictionary. Then the useragent converts that into a DOMTransaction and
stores it in the UndoManager's history. So, item would return a
DOMTransaction. In that case, merge could be a value in the Dictionary and
readonly on the DOMTransaction.
So one big use pattern we're predicting is something along the line of:
undoManager.transact(transactionFactory(~~));
where transactionFactory can create a custom DOM transaction object. Now
all properties set on the object returned by transactionFactory will be
lost when execute/executeAutomatic/undo/redo are called in your proposal,
and that's very counter intuitive and weird in my opinion.
We disagree on what's counterintuitive.
- Ryosuke
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
Arthur Barstow: 2. The patch [3] to remove the TreatNonCallableAsNull qualifier for some attributes. If anyone considers this change as substantive, please speak up. Cameron - what's your opinion on this? [TreatNonCallableAsNull] attribute Function? should be equivalent to attribute EventHandler so I would class it as an editorial change.
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On Wed, 11 Jul 2012, Julian Reschke wrote: OK; the amount of work is ~45 minutes (and probably can be automated for future publication cycles). See attachments; an edited version of the current editor's draft, and the diffs. ... ..and the diff was reversed; new version attached. Applying that diff to the spec on dev.w3.org is dumb, as it will just get blown away the next time I update the spec. If you actually want to help please e-mail me (as I suggested on the bug) and I can provide you with the relevant files against which to write the diff so that it will be maintained in future versions of the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [File API] File behavior under modification
On Wed, Jul 11, 2012 at 2:53 PM, Arun Ranganathan aranganat...@mozilla.comwrote: I agree that making snapshotting clearer might be a good idea. It is true that reading size and lastModifiedDate are synchronous, but this seemed a small trade-off compared to data reads. My instinct is that an asynchronous API for mtime is overkill. All disk I/O needs to be asynchronous. It doesn't matter how much data you're reading. If the file you're reading happens to be on a DVD that needs to spin up, or a slow or timing-out NFS mount, or even on a hard drive that happens to be powered down to save battery, reading anything at all can take a very long time. Disk I/O needs to be treated like network access. (While I'm thining about it, does lastModifiedDate really need to be nullable? Systems without file timestamps are so rare that it's probably better to require them to fabricate a date, so we don't introduce bugs into people's code for rare cases.) What's the main problem with it being nullable? A fabricated date seems strange, but instead of being nullable we could spec what the fabricated date is. I'm just not totally sure what the pros and cons are here. If you call d.getYear() and d is null, you get an exception, which has a very high chance of breaking the app if it's not checked for. Giving an arbitrary (but well-defined) default is much less likely to break things that badly. This is much more important when the null case is rare, because nobody is going to remember to test for it. Can you log a bug so that I can provide guidance for this in spec? Sorry, but to avoid rereading the thread, a bug for what exactly? Do you need anything beyond https://www.w3.org/Bugs/Public/show_bug.cgi?id=17746? On Wed, Jul 11, 2012 at 3:02 PM, Arun Ranganathan aranganat...@mozilla.comwrote: It would be the values at the time of the snapshot state. (I doubt it was ever actually intended that lastModifiedDate always return the file's latest mtime. We'll find out when one of the editors gets around to this thread...) I think the ideal behavior is that it reflects values at snapshot state, but that reads if snapshot state has modified fail. To be clear--reads of the blob data fail (FileReader), but .size or .lastModifiedDate continue to have their original values. -- Glenn Maynard
Re: [File API] File behavior under modification
On Wed, Jul 11, 2012 at 7:02 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jul 11, 2012 at 2:53 PM, Arun Ranganathan aranganat...@mozilla.com wrote: I agree that making snapshotting clearer might be a good idea. It is true that reading size and lastModifiedDate are synchronous, but this seemed a small trade-off compared to data reads. My instinct is that an asynchronous API for mtime is overkill. All disk I/O needs to be asynchronous. Indeed. All APIs which generate File objects based on IO create the File objects asynchronously. This to enable the implementation to get the size and lastModification date asynchronously and then store it in the File object. For the rest of the lifetime of the File object these numbers represent a snapshot. Hence to access the loastModifiedDate doesn't require any IO. The implementation only needs to returned the saved value. / Jonas
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On 2012-07-12 01:52, Ian Hickson wrote: On Wed, 11 Jul 2012, Julian Reschke wrote: OK; the amount of work is ~45 minutes (and probably can be automated for future publication cycles). See attachments; an edited version of the current editor's draft, and the diffs. ... ..and the diff was reversed; new version attached. Applying that diff to the spec on dev.w3.org is dumb, as it will just get As the other changes the W3C team applies to the spec when it gets published. blown away the next time I update the spec. If you actually want to help please e-mail me (as I suggested on the bug) and I can provide you with the relevant files against which to write the diff so that it will be maintained in future versions of the spec. My interest was to demonstrate the problem, and to fix it for the pending publication. In the process of it, I also discovered that one term used in the spec is undefined. Go ahead and claim that's not helpful; I beg to differ. Best regards, Julian
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On Thu, Jul 12, 2012 at 5:44 AM, Julian Reschke julian.resc...@gmx.de wrote: My interest was to demonstrate the problem, and to fix it for the pending publication. In the process of it, I also discovered that one term used in the spec is undefined. Except as you can see in the more helpful version of the specification at http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html the term is in fact defined. Go ahead and claim that's not helpful; I beg to differ. -- http://annevankesteren.nl/
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On 2012-07-12 07:16, Anne van Kesteren wrote: On Thu, Jul 12, 2012 at 5:44 AM, Julian Reschke julian.resc...@gmx.de wrote: My interest was to demonstrate the problem, and to fix it for the pending publication. In the process of it, I also discovered that one term used in the spec is undefined. Except as you can see in the more helpful version of the specification at http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html the term is in fact defined. ... What we are discussing here is the W3C version of the spec; that one will reference the W3C HTML5 spec (as far as I can tell), which does not. It almost seems to me that nobody cares over here what the W3C document actually says, as there is that other more helpful version. In which case I wonder why it's published at all? Best regards, Julian
