Going a bit back to current spec and changing underlying files - here is an
update on our thinking (and current implementation plan). We played with
File/Blob ideas a little more and talked with some of our app developers. In
regard to a problem of changing file, most folks feel the Blob is best
On Mon, Feb 1, 2010 at 12:27 PM, Dmitry Titov dim...@chromium.org wrote:
Basically, it's app-specific choice. It appears that the
following implementation goes along with the current edition of the spec but
also provides the ability to detect the file change:
1. File derives from Blob, so
On Sun, Jan 24, 2010 at 8:04 AM, Juan Lanus juan.la...@gmail.com wrote:
** Locking
What's wrong with file locking?
Rob O'Callahan answered that:
One problem is that mandatory locking is not supported on Mac or most Linux
installs.
Quite right Bob. But still the lock is the way to go. At
On Wed, Jan 27, 2010 at 5:38 AM, Juan Lanus juan.la...@gmail.com wrote:
Quite right Bob. But still the lock is the way to go. At least as of today.
HTML5 might be mainstream for the next 10 years, starting rather soon.
In the meanwhile OSs will also evolve, in a way that we can't tell
now.
On Sun, Jan 24, 2010 at 8:04 AM, Juan Lanus juan.la...@gmail.com wrote:
** Locking
What's wrong with file locking?
One problem is that mandatory locking is not supported on Mac or most Linux
installs.
Rob
--
He was pierced for our transgressions, he was crushed for our iniquities;
the
I'm new to this list and to all the W3C work so I might be completely
wrong. That said, let's say.
Dmitry posed a simple question: If a file's blob should be kept in
sync with the file's content in disk, or not. He did not get a yes
or no answer but instead triggered a near 30 posts thread that
Treating blobs as snapshots sounds like a reasonable approach and it will
make the life of the chunked upload and other scenarios easier. Now the
problem is: how do we get the blob (snapshot) out of the file?
1) We can still keep the current relationship between File and Blob. When we
slice a
One thing to remember here is that if we require snapshotting, that
will mean paying potentially very high costs every time the
snapshotting operation is used. Potetially copying hundreds of
megabytes of data (think video).
But if we don't require snapshotting, things will only break if the
user
On Thu, Jan 21, 2010 at 12:49 PM, Jonas Sicking jo...@sicking.cc wrote:
One thing to remember here is that if we require snapshotting, that
will mean paying potentially very high costs every time the
snapshotting operation is used. Potetially copying hundreds of
megabytes of data (think
I think the 'snapshotting' discussed above does not imply the actual copy of
data, sync or async. The proposal seems to be to 'snapshot' enough
information (in case of file on a disk - the modification time is enogh) so
that later read operations can fail reliably if the Blob is out of sync with
What we mean for snapshotting here is not to copy all the underlying data.
Instead, we only intend to capture the least information needed in order to
verify if the underlying data have been changed.
I agreed with Eric that the first option could cause inconsistent semantics
between File.slice
So it seems there is 2 ideas on how to handle the underlying file changes in
case of File and Blob objects, nicely captured by Arun above:
1. Keep all Blobs 'mutating', following the underlying file change. In
particular, it means that Blob.size and similar properties may change from
query to
On Wed, Jan 20, 2010 at 1:45 PM, Dmitry Titov dim...@chromium.org wrote:
So it seems there is 2 ideas on how to handle the underlying file changes in
case of File and Blob objects, nicely captured by Arun above:
1. Keep all Blobs 'mutating', following the underlying file change. In
particular,
On Wed, Jan 20, 2010 at 2:30 PM, Eric Uhrhane er...@google.com wrote:
I think it could. Here's a third option:
Make all blobs, file-based or not, just as async as the blobs in
option 2. They never do sync IO, but could potentially fail future
read operations if their metadata is out of
On Wed, Jan 20, 2010 at 3:23 PM, Dmitry Titov dim...@chromium.org wrote:
On Wed, Jan 20, 2010 at 2:30 PM, Eric Uhrhane er...@google.com wrote:
I think it could. Here's a third option:
Make all blobs, file-based or not, just as async as the blobs in
option 2. They never do sync IO, but could
I don't think we should worry about underlying file changes.
If the app wants to cut a file into parts and copy them separately, then
perhaps the app should first copy the file into a private area. (I'm
presuming that one day, we'll have the concept of a chroot'd private file
storage area for a
On Thu, Jan 14, 2010 at 11:58 PM, Darin Fisher da...@chromium.org wrote:
I don't think we should worry about underlying file changes.
If the app wants to cut a file into parts and copy them separately, then
perhaps the app should first copy the file into a private area. (I'm
presuming that
On Fri, Jan 15, 2010 at 10:19 AM, Dmitry Titov dim...@chromium.org wrote:
Nobody proposed locking the file. Sorry for being unclear if that sounds
like it. Basically it's all about timestamps.
As Chris proposed earlier, a read operation can grab the timestamp of the
file before and after
On Fri, Jan 15, 2010 at 10:19 AM, Dmitry Titov dim...@chromium.org wrote:
Nobody proposed locking the file. Sorry for being unclear if that sounds
like it. Basically it's all about timestamps.
As Chris proposed earlier, a read operation can grab the timestamp of the
file before and after
On Fri, Jan 15, 2010 at 11:42 AM, Dmitry Titov dim...@chromium.org wrote:
On Fri, Jan 15, 2010 at 10:36 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jan 15, 2010 at 10:19 AM, Dmitry Titov dim...@chromium.org
wrote:
Nobody proposed locking the file. Sorry for being unclear if that
It seems that we feel that when a File object is sent via either Form or
XHR, the latest underlying version should be used. When we get a slice via
Blob.slice, we assume that the underlying file data is stable since then.
So for uploader scenario, we need to cut a big file into multiple pieces.
On Tue, Jan 12, 2010 at 5:28 PM, Chris Prince cpri...@google.com wrote:
For the record, I'd like to make the read atomic, such that you can
never get half a file before a change, and half after. But it likely
depends on what OSs can enforce here.
I think *enforcing* atomicity is difficult
Atomic read is obviously a nice thing - it would be hard to program against
API that behaves as unpredictably as a single read operation that reads half
of old content and half of new content.
At the same note, it would be likely very hard to program against Blob
objects if they could change
For the record, I'd like to make the read atomic, such that you can
never get half a file before a change, and half after. But it likely
depends on what OSs can enforce here.
I think *enforcing* atomicity is difficult across all OSes.
But implementations can get nearly the same effect by
Hi,
Does the Blob, which is obtained as File (so it refers to an actual file on
disk) track the changes in the underlying file and 'mutates', or does it
represent the 'snapshot' of the file, or does it become 'invalid'?
Today, if a user selects a file using input type=file, and then the file
on
Adding reply from Jonas Sicking from anther list (which I used first by
mistake :( )
Technically, you should send this email to the webapps mailing list,
since that is where this spec is being developed.
That said, this is a really hard problem, and one that is hard to
test. One thing that we
26 matches
Mail list logo
