On 1/12/12 12:53 PM, Arun Ranganathan wrote:
Oh I'm glad to see this one! Is it Blob and File that can be put
into
IDB? How do I create a new File (with a name field) from a Blob?
Charles: see the thread on making Blobs constructable -- follow
On 1/13/12 11:13 AM, Arun Ranganathan wrote:
On 1/12/12 12:53 PM, Arun Ranganathan wrote:
Oh I'm glad to see this one! Is it Blob and File that can be
put into IDB? How do I create a new File (with a name field)
from a Blob?
Charles: see the thread on making
That would be bad; it would require null checks that people would forget to
perform due to the rarity of the condition. Instead, it should return a
File that fails when read attempts are made. (Of course, those errors are
also rare, but it's at least not adding a *new* rare case.)
On Jan 13,
On Wed, Jan 11, 2012 at 12:35 PM, Charles Pritchard ch...@visc.us wrote:
On 1/11/2012 12:27 PM, Eric U wrote:
On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchardch...@jumis.com
wrote:
On 1/11/2012 9:00 AM, Glenn Maynard wrote:
This isn't properly specced anywhere and may be impossible to
Side-effects of event registration are outside of the DOM event model. UAs
can do whatever transparent optimizations they want, of course, but APIs
shouldn't *depend* on that for efficient implementations.
Occasional polling definitely has significant overhead (directories may
have tens of
On Jan 12, 2012, at 6:58 AM, Kyle Huey m...@kylehuey.com wrote:
On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard gl...@zewt.org wrote:
FYI, I don't think this is clear for File from the spec. It's even more
important if File objects are stored in History or IndexedDB; that it should
be a
On 1/12/2012 12:30 AM, Jonas Sicking wrote:
On Wed, Jan 11, 2012 at 12:35 PM, Charles Pritchardch...@visc.us wrote:
On 1/11/2012 12:27 PM, Eric U wrote:
On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchardch...@jumis.com
wrote:
On 1/11/2012 9:00 AM, Glenn Maynard wrote:
This isn't
On 1/12/2012 6:34 AM, Glenn Maynard wrote:
Side-effects of event registration are outside of the DOM event
model. UAs can do whatever transparent optimizations they want, of
course, but APIs shouldn't *depend* on that for efficient
implementations.
Occasional polling definitely has
That's not good enough for many use cases. For example, a notepad app that
saves to disk wants to update the display if another program modifies the
file. You don't want that to be delayed until you scan the directory; you
want the event pushed at you immediately when it happens. This is how I
On Jan 12, 2012, at 6:58 AM, Kyle Huey m...@kylehuey.com wrote:
On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard gl...@zewt.org
wrote:
FYI, I don't think this is clear for File from the spec. It's
even
more important if File objects are stored in History or
IndexedDB;
On 1/12/12 12:53 PM, Arun Ranganathan wrote:
On Jan 12, 2012, at 6:58 AM, Kyle Huey m...@kylehuey.com
mailto:m...@kylehuey.com wrote:
On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard gl...@zewt.org
mailto:gl...@zewt.org wrote:
FYI, I don't think this is clear for
I don't follow. Either the user always has to poll the Entry to trigger
the event, or you never have to. The former defeats the purpose of having
an event (optimized by OS change notifications, low-overhead and
instantaneous); the latter may not be possible (NFS). You can't have a web
API where
On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard ch...@jumis.com wrote:
On 1/11/2012 9:00 AM, Glenn Maynard wrote:
This isn't properly specced anywhere and may be impossible to implement
perfectly, but previous discussions indicated that Chrome, at least, wanted
File objects loaded from
On 1/11/2012 12:27 PM, Eric U wrote:
On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchardch...@jumis.com wrote:
On 1/11/2012 9:00 AM, Glenn Maynard wrote:
This isn't properly specced anywhere and may be impossible to implement
perfectly, but previous discussions indicated that Chrome, at
(Pardon the top-quoting and poor editing; working off a phone today.)
This isn't properly specced anywhere and may be impossible to implement
perfectly, but previous discussions indicated that Chrome, at least, wanted
File objects loaded from input elements to only represent access for the
file
On 1/11/2012 9:00 AM, Glenn Maynard wrote:
This isn't properly specced anywhere and may be impossible to
implement perfectly, but previous discussions indicated that Chrome,
at least, wanted File objects loaded from input elements to only
represent access for the file as it is when the user
On Tue, Jan 10, 2012 at 10:57 PM, Charles Pritchard ch...@jumis.com wrote:
Far as I can tell, File is live, and it's supposed to be live from input
type=file.
FWIW, I (and I believe others at Mozilla) consider the fact that File
objects are live in Gecko a bug. Fixing this is kind of
On 1/11/2012 12:37 PM, Kyle Huey wrote:
On Tue, Jan 10, 2012 at 10:57 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
Far as I can tell, File is live, and it's supposed to be live from
input type=file.
FWIW, I (and I believe others at Mozilla) consider the fact
On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard ch...@visc.us wrote:
Modern operating systems have efficient mechanisms to send a signal when a
watched file or directory is modified.
File and FileEntry have a last modified date-- currently we must poll entries
to see if the modification
On Jan 10, 2012, at 1:53 PM, Eric U er...@google.com wrote:
On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard ch...@visc.us wrote:
Modern operating systems have efficient mechanisms to send a signal when a
watched file or directory is modified.
File and FileEntry have a last modified
20 matches
Mail list logo
