- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Tue, 11 Aug 2009 16:18:10 -0700
- To: Olli Pettay <Olli.Pettay@helsinki.fi>
- Cc: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>, arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Aug 11, 2009 at 2:25 PM, Olli Pettay<Olli.Pettay@helsinki.fi> wrote: > On 8/11/09 11:57 PM, Jonas Sicking wrote: >> >> My concern isn't that there are ways of using it correctly, my concern >> is that it's very easy to use incorrectly with bugs as a result. > > How? Especially if we prevent more than one read at time. How is the > situation any worse than with XHR? > As stated, anyone can request a resource via XHR at anytime. Old CGI progs were single threaded, but modern programs are multi-threaded (e.g. Servlet), there is no prerequisite to ask the server if a file read is OK first. Caller makes an XHR and it either succeeds or doesn't. XHR doesn't require expectation on the caller; what state is the file in. Besides a file shouldn't be having behavior (read, write, delete). Insted it hould be just having some properties like "name" or "size". A good reason for having a separate object for read(). More in mail to Jonas,. I'm not done with that mail yet. Garrett > >> This >> concern exists as long as the read API is available on the File object >> itself. We could make File not inherit FileData, but that wasn't the >> proposal made so far. >> >> Also note that progress events don't contain the actual data. So so >> far no-one has made a proposal what allows for streaming, which I >> would have thought would be an integral part of progress events. > > Indeed. Progress events should be probably extended to contain data. > (Progress Events Level 2?) > > > -Olli > >
Received on Tuesday, 11 August 2009 23:18:50 UTC