Re: Polished FileSystem API proposal
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 instead? Is this value 0-based?
PromiseFile getFile();
AbortableProgressPromiseArrayBuffer read(unsigned long long size);
AbortableProgressPromiseDOMString readText(unsigned long long
size, optional DOMString encoding = utf-8);
void abort();
};
interface FileHandleWritable : FileHandle
{
AbortableProgressPromisevoid write((DOMString or ArrayBuffer or
ArrayBufferView or Blob) value);
Promisevoid setSize(optional unsigned long long size);
Promisevoid flush();
};
partial interface URL {
static DOMString? getPersistentURL(File file);
}
// WebIDL cruft that's largely transparent
enum PersistenceType { temporary, persistent };
dictionary FilesystemParameters {
PersistenceType storage = temporary;
};
dictionary MakeFileOptions {
boolean overwriteIfExists = false;
(DOMString or Blob or ArrayBuffer or ArrayBufferView) data;
};
enum CreateMode { createifneeded, dontcreate }
enum DeleteMode { recursive, nonrecursive }
dictionary DestinationDict {
Directory dir;
DOMString name;
};
enum FileOpenMode { read, write, append };
[...]
Do we really need the .openAppend() function? Or is it ok to ask
people to use .openWrite() and then go to the end before writing?
In the append mode, is the location in file changed to the end of
file before every write? If not, then I think openAppend should be
removed. In the example you gave at the bottom of your message, it seems
that it's actually possible to write in the middle of the file.
Another non-posix thing is that you can read a file that is in write mode.
I would therefore propose to:
* remove openAppend()
* change enum FileOpenMode to {read, readWrite}
In another email you wrote that this API is not meant to be used to
access the OS filesystem, but a snadboxed filesystem abstraction for a
webapp. If so, why do we even need the two access modes? Let's just have
an openFile() that returns a File object you can read and write to.
--
Janusz Majnert
Samsung RD Institute Poland
Samsung Electronics
Re: Polished FileSystem API proposal
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 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 instead? Is this value 0-based?
That seems better yeah.
Do we really need the .openAppend() function? Or is it ok to ask
people to use .openWrite() and then go to the end before writing?
In the append mode, is the location in file changed to the end of
file
before every write?
No. It's just initially set to the end of the file. Though since every
write moves the offset to the end of the write, that means that the
offset will remain at the end of the file unless explicitly set.
Yes, but if you change the offset to point to the beginnig of the file,
then a subsequent write happens there, unlike in posix, which would first
move the pointer to the eof and then write the data.
IMHO openAppend should be dropped. It will confuse people used to posix
style file access, and for others it's just a shorthand for
openWrite+location=null.
If not, then I think openAppend should be removed. In
the example you gave at the bottom of your message, it seems that it's
actually possible to write in the middle of the file.
It is indeed.
Another non-posix thing is that you can read a file that is in write
mode.
I would therefore propose to:
* remove openAppend()
* change enum FileOpenMode to {read, readWrite}
In another email you wrote that this API is not meant to be used to
access
the OS filesystem, but a snadboxed filesystem abstraction for a
webapp. If
so, why do we even need the two access modes? Let's just have an
openFile()
that returns a File object you can read and write to.
I can think of four reasons, though none of them particularly great.
* While it's not a primary target for this API, it's nice if we can
reuse the same API if we ever end up introducing APIs that will allow
accessing real filesystems. Though you could argue that it's ok if you
in that case too always open the file in readwrite mode.
* Even in a sandboxed filesystem you could end up with multiple actors
accessing the filesystem at the same time. For example the user might
have the same website open in two tabs. Or you might have a worker and
a page accessing the file at the same time. With openRead you can
allow multiple simultaneous readers.
* We might want to support a read-only filesystem in some situations.
For example if the user uses drag'n'drop to expose a folder to a page,
we could expose that folder using a read-only version of the Directory
interface. Though in that case not exposing open* at all and instead
relying on get() would probably work.
* A main reason we're considering exposing a filesystem API at all is
it's a familiar concept to authors. And most filesystem APIs have
openRead and openWrite (and posix has openAppend).
/ Jonas
Re: Polished FileSystem API proposal
2013/7/22 pira...@gmail.com pira...@gmail.com: Adding something like inotify would also enable use cases like having a worker synchronize a filesystem to a server. Other parts of the application could simply access the filesystem directly and do whatever modifications it wants. Those notifications will automatically be noticed and synchronized to the server by the worker. Hell yes!!! +1000 to add an interface to inotify :-D I'm concerned that you're taking this API too far. What's next - mmaping a file to a byte array? It was supposed to be simple, sandboxed API for storing data in file-like structures - let's maybe get this thing working first? /Janusz Majnert
Re: HTML Import for Web Designers
Hi, On 09.04.2015 10:46, Rahly wrote: I've tried searching for messages regarding duplicate custom elements, but I haven't found anything. Has this been addressed? Some reading material: https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0452.html https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0783.html Regards, Janusz Majnert Senior Software Engineer Samsung RD Institute Poland Samsung Electronics
