Hi,
On 2013-07-13 02:31, Jonas Sicking wrote:
[...]
interface FileHandle
{
readonly attribute FileOpenMode mode;
readonly attribute boolean active;
attribute long long? location;
location seems to be a bad name. It might be confused with location
in the filesystem. Why not use offset
I agree, the available libraries that currently exists not only are
slow compared to native code (I don't know of anyone that use the
trick used on the demos scene of canvas.getasbytestring() ) and to
speed up things they use webworkers, so they are difficult to use from
file:// scheme pages.
On Mon, Jul 15, 2013 at 12:18 AM, Janusz Majnert j.majn...@samsung.com wrote:
Hi,
On 2013-07-13 02:31, Jonas Sicking wrote:
[...]
interface FileHandle
{
readonly attribute FileOpenMode mode;
readonly attribute boolean active;
attribute long long? location;
location seems to
Hi All,
One of the features that the sandboxed filesystem storage area brings
over indexedDB is the filesystem: URL scheme. Or more precisely, the
ability to load something from filesystem storage using a URL, without
having to use the filesystem JS API at all.
There is no technical reason we
15 lip 2013 10:47, Jonas Sicking jo...@sicking.cc napisał(a):
On Mon, Jul 15, 2013 at 12:18 AM, Janusz Majnert j.majn...@samsung.com
wrote:
Hi,
On 2013-07-13 02:31, Jonas Sicking wrote:
[...]
interface FileHandle
{
readonly attribute FileOpenMode mode;
readonly
On Mon, Jul 15, 2013 at 11:04 AM, Joshua Bell jsb...@google.com wrote:
On Mon, Jul 15, 2013 at 1:57 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
One of the features that the sandboxed filesystem storage area brings
over indexedDB is the filesystem: URL scheme. Or more precisely, the
On Mon, Jul 15, 2013 at 2:30 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't feel very strongly. I just know there tends to be a lot of
political overhead to adding new schemes, and I'm worried about the
outcry if we try to add both indexeddb: and filesystem:
There is some overhead in adding
On Mon, Jul 15, 2013 at 2:42 PM, Eric U er...@google.com wrote:
75% bikeshedding, 25% lessons learned:
It seems inconsistent to have the API for recursion done differently
in two different parts of the API: you've got two functions for
enumerate/enumerateDeep but remove takes a parameter to
So exposing FormData's contents came up again. The natural model is to
have FormData be map of string to either a string or File object. This
is very much equivalent to exposing a constructor for File to create a
Blob with a filename. I was told people objected to that in the past.
What were the
On Mon, Jul 15, 2013 at 4:47 PM, Eric U er...@google.com wrote:
What's the purpose of DestinationDict? It seems redundant.
There's basically three potential ways to specify a copy/move destination:
Specify a new name within the current directory.
Specify a new directory but keep the current
Hi,
I am not a big fan of the Directory approach of this proposal. It puts
the API between a high level, object oriented API and a low level API.
It is unfortunately not really high level because you have to use the
Directory for most operations and the File objects can't be subject to
any
On Jul 15, 2013, at 8:01 PM, Anne van Kesteren wrote:
So exposing FormData's contents came up again.
Can you send me a pointer to that discussion, so I can plug into it?
The natural model is to
have FormData be map of string to either a string or File object. This
is very much
12 matches
Mail list logo
