- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 12 Aug 2009 02:39:27 +0300
- To: Garrett Smith <dhtmlkitchen@gmail.com>
- 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 8/12/09 2:18 AM, Garrett Smith wrote: > 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. But if some other caller has used the same XHR, the request may be in-process and making a new request cancels the previous one. I think FileData could have similar behavior. Getting the actual data from FileData is the "request". It succeeds or not. Just like with XHR. > > Besides a file shouldn't be having behavior (read, write, delete). Why not? (This is really a question :) ) > Insted it hould be just having some properties like "name" or "size". > A good reason for having a separate object for read(). Well, sure, if there is a use case, File could be a separate object and not extend FileData. -Olli
Received on Tuesday, 11 August 2009 23:40:21 UTC