Delay in File * spec publications in /TR/ [Was: CfC: publish LCWD of File API; deadline March 3]
Hi All - the publication of the File API LC was delayed because of some logistical issues for Arun as well as some additional edits he intends to make. This delay also resulted in Eric's two File * specs not being published since they have a dependency on the latest File API spec. Arun - can you please give us at least a rough idea when you expect the spec to be ready for LC publication? Jonas - as co-Editor of File API, can you help get the File API LC published? Eric - your File * docs were last published in April 2011 so I think it would be good to get new versions published in /TR/ soon-ish. OTOH, if they have dependencies on the latest File API, it may be better to postpone their publication until File API is published. WDYT? -Thanks, ArtB On Feb 25, 2012, at 7:19 AM, Arthur Barstow wrote: Comments and bugs submitted during the pre-LC comment period for File API spec have been addressed and since there are no open bugs, this is a Call for Consensus to publish a LCWD of the File API spec using the latest ED as the basis: http://dev.w3.org/2006/webapi/FileAPI/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by March 3 at the latest. Positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -Thanks, AB
Re: File API oneTimeOnly is too poorly defined
2012/3/29 Bronislav Klučka bronislav.klu...@bauglir.com
If I understand you, you find it problematic that by using weak ref, URL
would for some time reference actual Blob and other time it would not?
The problem is that the following code might or might not work, depending
on the behavior of the browser's GC:
url = createObjectURL(blob);
blob = null;
setTimeout(function() { img.src = url; }, 0);
If the timer executes before GC collects the blob, this works, because the
URL is still valid. Otherwise, it fails, because--since the Blob no longer
exists--the URL is no longer valid.
--
Glenn Maynard
Re: File API oneTimeOnly is too poorly defined
On 30.3.2012 15:21, Glenn Maynard wrote:
2012/3/29 Bronislav Klučka bronislav.klu...@bauglir.com
mailto:bronislav.klu...@bauglir.com
If I understand you, you find it problematic that by using weak
ref, URL would for some time reference actual Blob and other time
it would not?
The problem is that the following code might or might not work,
depending on the behavior of the browser's GC:
url = createObjectURL(blob);
blob = null;
setTimeout(function() { img.src = url; }, 0);
If the timer executes before GC collects the blob, this works, because
the URL is still valid. Otherwise, it fails, because--since the Blob
no longer exists--the URL is no longer valid.
--
Glenn Maynard
That should not be problematic; yes, GC may actually free that blob
allocated memory later than that timeout function triggers, but there is
explicit release of that blob (blob = null), so this must fail (memory
might be allocated by blob data, but that variable should be out). But
following may cause the same issue
var url = createObjectUrl(new Blob(['hello']));
setTimeout(function() { img.src = url; }, 0);
and even this in some aggressive GC implementation
img.src = createObjectUrl(new Blob(['hello']));
//since nothing references this blob, it could be destroyed right after
function ends, but before assigning result,
// thou GC works most likely in some application idle state not to delay
application process, theoretically this
// applies as well, since the functionality of GS is not specified =
implementation specific
Thou I could live with such issue, I see the problem (from others
programmers perspective and from specification perspective)... there's
no light at the end of this tunnel...
Either carefully treat weak refs, or have one time ULRs with
dereferencing and concurrency issues, or explicit URL release one might
forget..
Brona
Re: Delay in File * spec publications in /TR/ [Was: CfC: publish LCWD of File API; deadline March 3]
On Fri, Mar 30, 2012 at 5:39 AM, Arthur Barstow art.bars...@nokia.com wrote: Hi All - the publication of the File API LC was delayed because of some logistical issues for Arun as well as some additional edits he intends to make. This delay also resulted in Eric's two File * specs not being published since they have a dependency on the latest File API spec. Arun - can you please give us at least a rough idea when you expect the spec to be ready for LC publication? Jonas - as co-Editor of File API, can you help get the File API LC published? Eric - your File * docs were last published in April 2011 so I think it would be good to get new versions published in /TR/ soon-ish. OTOH, if they have dependencies on the latest File API, it may be better to postpone their publication until File API is published. WDYT? If it's going to be more than a month to get Arun+Jonas's spec up, we might as well go ahead and publish mine; they've had quite a bit of change. If it's less than that, let's just do them all together. -Thanks, ArtB On Feb 25, 2012, at 7:19 AM, Arthur Barstow wrote: Comments and bugs submitted during the pre-LC comment period for File API spec have been addressed and since there are no open bugs, this is a Call for Consensus to publish a LCWD of the File API spec using the latest ED as the basis: http://dev.w3.org/2006/webapi/FileAPI/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by March 3 at the latest. Positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -Thanks, AB
Re: CfC Re: Charter addition proposal: screen orientation lock
On 02/15/2012 10:09 AM, Vincent Scheib wrote: Mounir, I ran into the same confusion regarding how does the API expose locking?. May I suggest that you explicitly state in the abstract that the API is pending? I just updated the draft so the locking part is now part of it. Cheers, -- Mounir
Re: CfC Re: Charter addition proposal: screen orientation lock
Great! Am 30.03.12 11:28 schrieb Mounir Lamouri unter mou...@lamouri.fr: On 02/15/2012 10:09 AM, Vincent Scheib wrote: Mounir, I ran into the same confusion regarding how does the API expose locking?. May I suggest that you explicitly state in the abstract that the API is pending? I just updated the draft so the locking part is now part of it. Cheers, -- Mounir
Re: File API oneTimeOnly is too poorly defined
2012/3/30 Bronislav Klučka bronislav.klu...@bauglir.com
url = createObjectURL(blob);
blob = null;
setTimeout(function() { img.src = url; }, 0);
That should not be problematic; yes, GC may actually free that blob
allocated memory later than that timeout function triggers, but there is
explicit release of that blob (blob = null), so this must fail (memory
might be allocated by blob data, but that variable should be out). But
following may cause the same issue
blob = null is not an explicit release of anything. It's just clearing a
reference. The only way to know that the blob is no longer referenced is
to wait for GC--that's what garbage collection *is*. It's impossible to
guarantee that the img.src = url above will fail (without placing severe
constraints on how GC can be implemented, which won't happen).
--
Glenn Maynard
[XHR] Constructor behavior seems to be underdefined
As far as I can tell, the WebIDL specification doesn't define anything about what really happens when a constructor is invoked, once the arguments have been converted to the IDL types, except the conversion of the return value from an IDL type to an ES type. It defers the exact behavior of the constructor to the specification defining the constructor. XHR2 currently says in http://www.w3.org/TR/XMLHttpRequest2/#constructors : The XMLHttpRequest() constructor must return a new XMLHttpRequest object. and in http://www.w3.org/TR/XMLHttpRequest2/#origin-and-base-url : In environments where the global object is represented by the Window object the XMLHttpRequest object has an associated XMLHttpRequest document which is the document associated with the Window object for which the XMLHttpRequest interface object was created. Now consider a web page with two subframes and a script that has references to the two subframe windows in variables w1 and w2. Then the script does this: w1.XMLHttpRequest = w2.XMLHttpRequest; var xhr = new w1.XMLHttpRequest(); What's the document associated with xhr? Is it w1.document, w2.document, or window.document? The concept the Window object for which the XMLHttpRequest interface object was created doesn't seem to be defined anywhere -Boris
Re: [XHR] Constructor behavior seems to be underdefined
See the [[Scope]] internal property of function objects from ECMA-262 13.2, 10.4.3, etc. /be Boris Zbarsky wrote: As far as I can tell, the WebIDL specification doesn't define anything about what really happens when a constructor is invoked, once the arguments have been converted to the IDL types, except the conversion of the return value from an IDL type to an ES type. It defers the exact behavior of the constructor to the specification defining the constructor. XHR2 currently says in http://www.w3.org/TR/XMLHttpRequest2/#constructors : The XMLHttpRequest() constructor must return a new XMLHttpRequest object. and in http://www.w3.org/TR/XMLHttpRequest2/#origin-and-base-url : In environments where the global object is represented by the Window object the XMLHttpRequest object has an associated XMLHttpRequest document which is the document associated with the Window object for which the XMLHttpRequest interface object was created. Now consider a web page with two subframes and a script that has references to the two subframe windows in variables w1 and w2. Then the script does this: w1.XMLHttpRequest = w2.XMLHttpRequest; var xhr = new w1.XMLHttpRequest(); What's the document associated with xhr? Is it w1.document, w2.document, or window.document? The concept the Window object for which the XMLHttpRequest interface object was created doesn't seem to be defined anywhere -Boris
Re: [XHR] Constructor behavior seems to be underdefined
On 3/30/12 9:22 PM, Brendan Eich wrote: See the [[Scope]] internal property of function objects from ECMA-262 13.2, 10.4.3, etc. Nothing in WebIDL or XHR says to use [[Scope]]. If it did, that would constitute a definition of the behavior, yes. -Boris
