Re: [FileAPI] No streaming semantics?
Use slice; webkitSlice.
They just it themselves put together on the media Apis as well. So that's cool.
There's an append stream semantic.
-Charles
On Feb 5, 2012, at 5:18 PM, Justin Summerlin wrote:
> I've been playing around with the FileAPI in both Chrome and Firefox. The
> API presented works very well for small files consistent with perhaps circa
> 1990s web usage. Previewing small images (~50K), reading and processing
> small files ("a few" MB) have been cases where uniformly strong results are
> seen and the proposed API appears to greatly enhance the capability of
> client-oriented JS-enabled websites.
>
> Upon considering the implications for local file processing, it became
> apparent to me that the repercussions for client-side filtering and
> aggregation can be a potentially huge thing for the internet. One simple
> case study demonstrates two-fold inadequacies in the presented File API for
> very commonly used semantics.
>
> Consider a web application designed to process user-submitted log files to
> perform analytics and diagnose problems. Perhaps these log files can
> typically be 50GB in size. Two cases are interesting:
>
> 1. The application scans through the log file looking for errors up to some
> maximum number, then reports those to a server-side script.
> 2. The application watches the log file and actively collects information on
> errors to recommend diagnostics (in this case, no round-trip may be
> necessary).
>
> The reason the first case cannot be implemented with the present API is that
> readAs* in FileReader reads the *entire* file into memory, firing progress
> events along the way. It is consistent that both Chrome and Firefox
> implementations attempt to do this and then fail due to insufficient memory.
> The reason the second case is impractical is that one must re-read the entire
> file into memory each time to see any changes in a file, which is problematic
> at best.
>
> Unless I'm missing something (I don't believe that I am), the capability of
> streaming which would solve both of these problems in a very effective way,
> is not present in the FileAPI. Perhaps in addition to readAs*, both seek and
> read[Text|BinaryString|ArrayBuffer](, [, ]).
> Additionally, in an asynchronous manner, the result is presented in an event:
>
> function processFile(file, reader) {
> reader.onread = function (ev) {
> if (has more...) {
> reader.readText(file, 4096);
> } else {
> reader.onread = null;
> }
> // Process chunk...
> }
> reader.readText(file, 4096);
> }
>
> And in the case of reading more data from a file as it's written to, one
> would simply keep attempting a read and if the read returns no data, do
> nothing.
>
> Is this intended and if so, is any streaming semantic to be considered in
> future JavaScript API considerations?
>
> Thanks,
>
> Justin
[FileAPI] No streaming semantics?
I've been playing around with the FileAPI in both Chrome and Firefox. The
API presented works very well for small files consistent with perhaps circa
1990s web usage. Previewing small images (~50K), reading and processing
small files ("a few" MB) have been cases where uniformly strong results are
seen and the proposed API appears to greatly enhance the capability of
client-oriented JS-enabled websites.
Upon considering the implications for local file processing, it became
apparent to me that the repercussions for client-side filtering and
aggregation can be a potentially huge thing for the internet. One simple
case study demonstrates two-fold inadequacies in the presented File API for
very commonly used semantics.
Consider a web application designed to process user-submitted log files to
perform analytics and diagnose problems. Perhaps these log files can
typically be 50GB in size. Two cases are interesting:
1. The application scans through the log file looking for errors up to some
maximum number, then reports those to a server-side script.
2. The application watches the log file and actively collects information
on errors to recommend diagnostics (in this case, no round-trip may be
necessary).
The reason the first case cannot be implemented with the present API is
that readAs* in FileReader reads the *entire* file into memory, firing
progress events along the way. It is consistent that both Chrome and
Firefox implementations attempt to do this and then fail due to
insufficient memory. The reason the second case is impractical is that one
must re-read the entire file into memory each time to see any changes in a
file, which is problematic at best.
Unless I'm missing something (I don't believe that I am), the capability of
streaming which would solve both of these problems in a very effective way,
is not present in the FileAPI. Perhaps in addition to readAs*, both seek
and read[Text|BinaryString|ArrayBuffer](, [,
]). Additionally, in an asynchronous manner, the result is
presented in an event:
function processFile(file, reader) {
reader.onread = function (ev) {
if (has more...) {
reader.readText(file, 4096);
} else {
reader.onread = null;
}
// Process chunk...
}
reader.readText(file, 4096);
}
And in the case of reading more data from a file as it's written to, one
would simply keep attempting a read and if the read returns no data, do
nothing.
Is this intended and if so, is any streaming semantic to be considered in
future JavaScript API considerations?
Thanks,
Justin
Re: data and blob URLs in HTTP context
On 2012-02-05 15:56, Anne van Kesteren wrote: Currently Opera and Firefox seem to support data URLs within the context of XMLHttpRequest. Status is 0, status text is the empty string, there are no response headers, and response-related attributes work as expected. ... No Content-Type response header? Best regards, Julian
Re: [XHR] Invoking open() from event listeners
On Wed, 18 Jan 2012 00:56:12 +0100, Eric U wrote: On Tue, Dec 20, 2011 at 9:24 AM, Anne van Kesteren wrote: open() does terminate both abort() and send() (the way it does so is not very clear), but maybe it would be clearer if invoking open() set some kind of flag that is checked by both send() and abort() from the moment they start dispatching events. http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html Ah, I see how that works now. So if you call open from onerror/onabort/onload, there's no loadend from the terminated XHR. And if you call open before onerror/onabort/onload, you don't get any of those either? Right. If you call open from onerror, do other listeners later in the chain get their onerror calls? Currently they would be invoked as there is no interference with the normal event dispatching rules. I'm really not sure what the best approach would be though. Advice welcome. If nobody has better ideas than what we now (taking into account compatibility of course) I will likely just clarify the situation as explained above. -- Anne van Kesteren http://annevankesteren.nl/
data and blob URLs in HTTP context
Currently Opera and Firefox seem to support data URLs within the context of XMLHttpRequest. Status is 0, status text is the empty string, there are no response headers, and response-related attributes work as expected. This is different from blob URLs in that blob URLs do have a response code (which would be always 200 for data URLs) and they can have response headers too (maybe we should remove that from blob URLs?). Are there any more such URLs? We should probably figure out the best way to define them including their overall behavior so we do not get inconsistent results. My current thinking is that they should have a useful status code, maybe a useful status text (does not matter much, but should be the empty string or a fixed string of sorts), and no response headers (there's no use case). -- Anne van Kesteren http://annevankesteren.nl/
Re: StreamBuilder threshold
On 01/26/2012 07:05 PM, Feras Moussa wrote: Can you please clarify what scenario you are looking at regarding multiple consumers? When designing the StreamBuilder API, we looked at it as a more primitive API which other abstractions (such as multiple consumers) can be built upon. (Please forgive me if I am making stupid input - I am in a learning phase). A very simple scenario would be the example in the draft that "demonstrates how to use StreamBuilder to load a stream into the audio tag". In this example the consumer is an audio tag, and new data is appended to the stream each time the buffer falls below 1024 bytes. Fine so far, but what happens if the same stream (via createObjectURL) is connected to one more audio tag, but at T ms later. In this case the first audio tag would have consumed down to the threshold (1024 bytes) T ms before the second. Another example could be that one Stream is uploaded using two parallel xhr's; one of them could have a couple of pakcet losses and then consume slower than the other (and if WS could take send(stream) the same would apply). If you can please let me know what issue you're trying to address, I'm happy to discuss the possibilities. I hope the above input explained the issue. Also, For future reference, the latest draft is now located on the W3 site at http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Thanks for updating me! Stefan Thanks, Feras -Original Message- From: Stefan Hakansson LK [mailto:stefan.lk.hakans...@ericsson.com] Sent: Tuesday, January 17, 2012 12:28 AM To: Feras Moussa; Travis Leithead Cc: public-webapps@w3.org Subject: StreamBuilder threshold I'm looking at http://html5labs.interoperabilitybridges.com/streamsapi/, and specifically at the StreamBuilder. It has the possibility to generate an event if the data available falls below a threshold. How is this supposed to work if there is more than one consumer, and those consumers either don't start consuming at exactly the same time or consume at different rates, of the Stream? --Stefan
[Bug 15902] New: DOMParser created documents should use about:blank as URL
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15902 Summary: DOMParser created documents should use about:blank as URL Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM Parsing and Serialization AssignedTo: ms2...@gmail.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Just like other documents without attachment to anything whatsoever, DOMParser documents should use "about:blank" as their URL. (And ideally implementations align.) -- 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.
[Bug 15901] New: Create "Participate:" box at top of the specification
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15901 Summary: Create "Participate:" box at top of the specification Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM Parsing and Serialization AssignedTo: ms2...@gmail.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Modern standards such as http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html have a nice "Participate" box so I don't have to find bug components and such. Make it happen! -- 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: StreamBuilder threshold
On Thu, 26 Jan 2012 19:05:05 +0100, Feras Moussa wrote: When designing the StreamBuilder API, we looked at it as a more primitive API which other abstractions (such as multiple consumers) can be built upon. We should not have a StreamBuilder API. We should have a Stream constructor, similar to how we should not have a BlobBuilder API, but a Blob constructor (and we do now, I believe). It's a lot cleaner and in line with best practices for platform API design (which are undocumented, unfortunately). -- Anne van Kesteren http://annevankesteren.nl/
Re: Encoding Spec and Encoding for readAsText
On Thu, 26 Jan 2012 22:57:35 +0100, Arun Ranganathan wrote: Few quick questions: 1. Can you review: http://dev.w3.org/2006/webapi/FileAPI/#encoding-determination I think per https://www.w3.org/Bugs/Public/show_bug.cgi?id=15359 we want to let the BOM checking happen before the other considerations. 2. How can I best coordinate this with the Encoding Specification that you are working on? I think eventually we want to update the text to no longer make use of the IANA registry (which is open ended) and just directly defer to the Encoding Standard (which only supports a fixed list of encodings). There is still some work to be done to finalize the latter though which is why I have not asked the HTML, DOM, File API etc. standards to update their text on the matter. I hope this clarifies the situation sufficiently. -- Anne van Kesteren http://annevankesteren.nl/
[Bug 15898] XTech 2000 (http://www.gca.org/attend/2000_conferences/xtech_2000/) is around the corner, and members of W3C team will be there, including Eric Prud'hommeaux, Michael Sperberg-McQueen,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15898 Ms2ger changed: What|Removed |Added Status|NEW |RESOLVED CC||ms2...@gmail.com Resolution||INVALID -- 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.
[Bug 15898] New: XTech 2000 (http://www.gca.org/attend/2000_conferences/xtech_2000/) is around the corner, and members of W3C team will be there, including Eric Prud'hommeaux, Michael Sperberg-McQu
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15898 Summary: XTech 2000 (http://www.gca.org/attend/2000_conferences/xtech_2000 /) is around the corner, and members of W3C team will be there, including Eric Prud'hommeaux, Michael Sperberg-McQueen, Henry Thompson, and Daniel Veillard. If you're going (or not), you may Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/webstorage/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: XTech 2000 (http://www.gca.org/attend/2000_conferences/xtech_2000/) is around the corner, and members of W3C team will be there, including Eric Prud'hommeaux, Michael Sperberg-McQueen, Henry Thompson, and Daniel Veillard. If you're going (or not), you may have questions regarding recent W3C developments, including XHTML 1.0 http://www.w3.org/TR/xhtml1 How W3C works http://www.w3.org/Consortium/ Plus, you might be interested in discussions of XML messaging, distributed computing, transactions, and protocols: http://lists.w3.org/Archives/Public/xml-dist-app In this spirit, we'd like to have a pre-conference chat - here are the details: Who: All are welcome W3C team members attending the chat include Dan Connolly, Masayasu Ishikawa, Eric Prud'hommeaux, Michael Sperberg-McQueen, Henry Thompson, and Daniel Veillard. Also from the HTML Working Group: Steven Pemberton and Shane McCarron When: Friday 25 February, at 1400Z (9am Eastern Time), for about an hour (Apologies to the parts of the world where that's inconvenient.) The log will go online - our previous chat is at: http://www.w3.org/1999/12/w3c-irc2409 Where: irc://irc.openprojects.net/#w3c i.e. channel #w3c on irc.openprojects.net about this IRC network, see Open Projects Network - New User? http://openprojects.nu/about.html stay tuned to the XML home page http://www.w3.org/XML/ for other details. What to bring: Send your pre-chat ideas, proposals, position papers, and "here's what I did with XHTML" to www-h...@w3.org Suggested reading: XHTML 1.0 http://www.w3.org/xhtml1 HTML Activity http://www.w3.org/Markup/ W3C Extensible Markup Language (XML) Activity http://www.w3.org/XML/Activity www-html mailing list http://lists.w3.org/Archives/Public/www-html xml-dist-app mailing list http://lists.w3.org/Archives/Public/xml-dist-app xml-dev mailing list http://www.lists.ic.ac.uk/hypermail/xml-dev/ http://www.egroups.com/list/xml-dev/info.html Subject: Call for Participation: W3C Public IRC Chat on XHTML Sat, 19 Feb 2000 11:33:17 +0100 http://www.egroups.com/group/xml-dev/18169.html? -- Dan Connolly http://www.w3.org/People/Connolly/ Posted from: 80.239.243.111 User agent: Opera/9.80 (Windows NT 5.1; U; ru) Presto/2.10.229 Version/11.61 -- 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.
