Re: Polished FileSystem API proposal
If the backend implementation used something like git's data store then duplicate data would automatically be stored only once without any security implications. The keys are the literal sha1 of the values. If two websites had the same file tree containing the same files, it would be the same tree object in the storage. But only sites who have a reference to the hash would have access to it. Also I like the level of fs support that git's filesystem has. There are trees, files, executable files, and symlinks. (there are also gitlinks used for submodules, but let's ignore those for now) On Tue, Nov 5, 2013 at 12:19 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 31, 2013 at 2:12 AM, Brian Stell bst...@google.com wrote: There could be *dozens* of copies of exactly the same a Javascript library, shared CSS, or web font in the FileSystem. Check out the cache part of https://github.com/slightlyoff/ServiceWorker/ Combined with a smart implementation that will do exactly what you want. And avoid all the issues of an actual cross-origin file system API. -- http://annevankesteren.nl/
Re: Polished FileSystem API proposal
On Tue, Nov 5, 2013 at 11:45 AM, Tim Caswell t...@creationix.com wrote: If the backend implementation used something like git's data store then duplicate data would automatically be stored only once without any security implications. The keys are the literal sha1 of the values. If two websites had the same file tree containing the same files, it would be the same tree object in the storage. But only sites who have a reference to the hash would have access to it. Also I like the level of fs support that git's filesystem has. There are trees, files, executable files, and symlinks. (there are also gitlinks used for submodules, but let's ignore those for now) Sounds like IndexedDB is a better fit than a filesystem for this use case. Note that the use case for the filesystem API isn't storing files, IDB is perfectly capable of doing that. The use case for the filesystem API is to satisfy people that want a true filesystem with directories etc so that they can: * Sync to a server-side file system. For example when doing web development and want to deploy a website. * Use hierarchical filesystem: URLs. * Support in-place editing of large files. * Because filesystems are familiar. A simple key-value storage, where the values happen to be files, doesn't need a filesystem API. / Jonas
Re: Define window.orientation
On Wed, Nov 6, 2013 at 12:17 AM, Jonas Sicking jo...@sicking.cc wrote: So unless webcompat at some point requiring it, I don't see us adding it. See OP. -- http://annevankesteren.nl/
Re: Thoughts behind the Streams API ED
I have seen the different bugs too, some comments: - maybe I have missed some explaination or some obvious thing but I don't understand very well right now the difference/use between readable/writablebytestream and bytestream - pause/unpause: as far as I understand the whatwg spec does not recommend it but I don't understand the reasons. As I previously mentionned the idea is to INSERT a pause signal in the stream, you can not control the stream and therefore know when you are pausing it. - stop/resume: same, see my previous post, the difference is that the consuming API should clone the state of the operation and close the current operation as if eof was received, then restart from the clone on resume - pipe []/fork: I don't see why the fast stream should wait for the slow one, so maybe the stream is forked and pause can be used for the slow one - flow control: could it be possible to advertise a maximum bandwidth rate for a stream? Regards Aymeric Le 04/11/2013 18:11, Takeshi Yoshino a écrit : I'd like to summarize my ideas behind this API surface since the overlap thread is too long. We'll put these into bug entries soon. Feedback on Overlap thread, especially Issac's exhaustive list of considerations and conversation with Aymeric were very helpful. In reply to his mail, I drafted my initial proposal [2] in past which addresses almost all of them. Since the API surface was so big, I tried to compact it while incorporating Promises. Current ED [3] addresses not all but some of important requirements. I think it's a good (re)starting point. * Flow control read() and write() in the ED does provide flow control by controlling the timing of resolution of the returned Promise. A Stream would have a window to limit data to be buffered in it. If a big value is passed as size parameter of read(), it may extend the window if necessary. In reading data as a DOMString, the size param of read() doesn't specify exact raw size of data to be read out. It just works as throttle to prevent internal buffer from being drained too fast. StreamReadResult tells how many bytes were actually consumed. If more explicit and precise flow control is necessary, we could cherry pick some from my old big API proposal [1]. For example, making window size configurable. If it makes sense, size can be generalized to be cost of each element. It would be useful when trying to generalize Stream to various objects. To make window dynamically adjustable, we could introduce methods such as drainCapacity(), expandCapacity() to it. * Passive producer Thinking of producers like a random number generator, it's not always good to ask a producer to prepare data and push it to a Stream using write(). This was possible in [2], but not in the ED. This can be addressed for example by adding one overload to write(). - write() and write(size) doesn't write data but wait until the Stream can accept some amount or the specified size of data. * Conversion from existing active and unstoppable producer API E.g. WebSocket invokes onmessage immediately when new data is available. For this kind of API, finite size Stream cannot absorb the production. So, there'll be need to buffer read data manually. In [2], Stream always accepted write() even if buffer is full assuming that if necessary the producer should be using onwritable method. Currently, only one write() can be issued concurrently, but we can choose to have Stream queue write() requests in it. * Sync read if possible By adding sync flag to StreamReadResult and introducing StreamWriteResult to signal if read was done sync (data is the actual result) or async (data is a Promise) to save Promise post tasking cost. I estimated that post tasking overhead should be negligible for bulk reading, and when to read small fields, we often read some amount into ArrayBuffer and then parse it directly. So it's currently excluded. * Multiple consumers pipe() can take multiple destination Streams. This allows for mirroring Stream's output into two or more Streams. I also considered making Stream itself consumable, but I thought it complicates API and implementation. - Elements in internal buffer need to be reference counted. - It must be able to distinguish consumers. If one of consumers is fast and the other is slow, we need to wait for the slower one before starting processing the rest in the original Stream. We can choose to allow multiple consumers to address this by introducing a new concept Cursor that represents reading context. Cursor can be implemented as a new interface or Stream that refers to (and adds reference count to elements of) the original Stream's internal buffer. Needs some more study to figure out if context approach is really better than pipe()-ing to new Stream instance. * Splitting InputStream (ReadableStream) and OutputStream (WritableStream) Writing part and reading part of the API can be split into two
Re: Polished FileSystem API proposal
On Nov 6, 2013 3:50 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 5, 2013 at 11:45 AM, Tim Caswell t...@creationix.com wrote: If the backend implementation used something like git's data store then duplicate data would automatically be stored only once without any security implications. The keys are the literal sha1 of the values. If two websites had the same file tree containing the same files, it would be the same tree object in the storage. But only sites who have a reference to the hash would have access to it. Also I like the level of fs support that git's filesystem has. There are trees, files, executable files, and symlinks. (there are also gitlinks used for submodules, but let's ignore those for now) Sounds like IndexedDB is a better fit than a filesystem for this use case. I'm not saying that I want a filesystem so I can implement git. I'm saying that git is a great way to implement a filesystem and that git's abilities are a great baseline for web filesystems. Note that the use case for the filesystem API isn't storing files, IDB is perfectly capable of doing that. The use case for the filesystem API is to satisfy people that want a true filesystem with directories etc so that they can: * Sync to a server-side file system. For example when doing web development and want to deploy a website. * Use hierarchical filesystem: URLs. * Support in-place editing of large files. * Because filesystems are familiar. Yes. I completely agree. Personally in my projects, I wish there was to create custom filesystems backed by JavaScript code that are exported to hierarchical URLs. It would work somewhat like server-side web development where a js function handles the request for a file. This is basically what fuse does for Linux. I would love to be able to create a custom union filesystem that has layers. One would be in-memory and another would be backed by a local bit database. It would all be implemented in pure user space js. A simple key-value storage, where the values happen to be files, doesn't need a filesystem API. Speaking of, I currently have a git implementation that uses IndexedDB as the data store. I don't call IDB simple by any means. I don't need transactions or indexes. The leveldb interface is much closer. To what I need to implement git. / Jonas So in summary: - The filesystem interface could export symlinks, files, trees, and executable bit. (Basically feature parity with git trees) - using a git style backing store (the content addressable part) is a great way to store data from multiple domains without duplicating storage or introducing security issues around sharing data. - I really want a fuse-like way to create virtual file systems where I implement the back end using user space code. - I want a key/value system that's simple like local storage, but async and supports binary values. Sorry for conflating so many topics in one email. They are all related and I'm new to this list. I'm not sure of the proper procedure for creating new topics. - Tim Caswell
Re: Polished FileSystem API proposal
Yes. I completely agree. Personally in my projects, I wish there was to create custom filesystems backed by JavaScript code that are exported to hierarchical URLs. It would work somewhat like server-side web development where a js function handles the request for a file. This is basically what fuse does for Linux. I would love to be able to create a custom union filesystem that has layers. One would be in-memory and another would be backed by a local bit database. It would all be implemented in pure user space js. Maybe you would be interested on ServiceWorkers https://github.com/slightlyoff/ServiceWorker They are currently being implemented on Firefox and Chrome. -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: Polished FileSystem API proposal
On Wed, Nov 6, 2013 at 8:46 AM, pira...@gmail.com pira...@gmail.com wrote: Yes. I completely agree. Personally in my projects, I wish there was to create custom filesystems backed by JavaScript code that are exported to hierarchical URLs. It would work somewhat like server-side web development where a js function handles the request for a file. This is basically what fuse does for Linux. I would love to be able to create a custom union filesystem that has layers. One would be in-memory and another would be backed by a local bit database. It would all be implemented in pure user space js. Maybe you would be interested on ServiceWorkers https://github.com/slightlyoff/ServiceWorker They are currently being implemented on Firefox and Chrome. That's very interesting and useful, but I don't think it fits the same use case I was talking about. I want the ability to create some object that exports an URL that I can put in an iframe. Then all requests from that iframe for resources will dynamically call my javascript code. I could implement the same logic that a server-side application does, but from local code in my browser. My particular use case is I'm developing an IDE to teach programming and would love to generate dynamic file systems that are then rendered in iframes or new windows. Having a better offline store than appcache is indeed useful, but I believe it's orthogonal to what I'm looking for here. Like Jonas said, Use hierarchical filesystem: URLs is exactly what I'm looking for and currently I can only do this in chrome with their html5 fs api. But instead of creating a temporary filesystem and writing files, I'd much rather if my code was called for every file request and I could dynamically generate the files on demand. -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: Polished FileSystem API proposal
That's very interesting and useful, but I don't think it fits the same use case I was talking about. I want the ability to create some object that exports an URL that I can put in an iframe. Then all requests from that iframe for resources will dynamically call my javascript code. I could implement the same logic that a server-side application does, but from local code in my browser. That's just the purpose of ServiceWorker :-) Only that from your message, I suspect you are asking about having the same functionality but only on the current session or maybe also only when the page is open, deleting it on reload. I don't know of anything like to this, the most similar ones would be FirefoxOS Browser API or Chrome FileSystem API, but nothing as powerful as ServiceWorker, sorry :-( They are talking about implementing the Fetch specification, maybe you would write them about allowing to be used someway the ServiceWorker functionality on a per-session basis, I find legitimate your proposition... -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix. – Linus Tordvals, creador del sistema operativo Linux
Re: Polished FileSystem API proposal
There are multiple interesting ideas being discussed 1. Mapping files to persistent URLs. 2. Sharing persistent URLs between different origins. 3. Using the ServiceWorker [1] to redirect URL requests (and possibly manage it's own cache / files) 4. De-duping file copies using a Git like scheme. 1. Mapping files to persistent URLs. == There are some things that could be considered 'ok' to be slow: images, video startup, list of unread emails. There are some things that are very time sensitive such as the initial page layout. This means that things like the CSS required for layout and the fonts required for layout need to be there before the body begins laying out; ie: they need to be available in the head section. If they are not then the page will irritatingly flash as the parts arrive. Unless I'm missing something, this means that objects retrieved by promises/callbacks are not fast enough. For these needed for layout objects, persistent URLs are very attractive as they can be retrieved quickly and in the head section. These persistent URLs can be implemented in a filesystem or IndexedDB or other mechanism. A ServiceWorker could remap the URL but the data would still need to be available locally (eg, on disk). 2. Sharing persistent URLs between different origins. == Right now, any interesting object that is used by different origins (even from the same organization) must be downloaded and stored once per origin. Imagine if Linux required glib to be separately stored for every executable. This is how the web works today. Shareable persistent URLs would allow for a single copy to be download and shared across origins. Like shared libraries the user of the shared object has to trust the providing origin and only the providing origin should be able to write the data. 3. Using the ServiceWorker to redirect URL requests (and possibly manage it's own cache / files) == The ServiceWorker provides a way for an web page to redirect URLs. This is a very attractive feature for applications that are offline (or have an unreliable connection). The redirected URL could be to a completely different URL or to data managed by the ServiceWorker itself; eg, the ServiceWorker could use the FileSystem API to store data and redirect URLs to that data. Hopefully, this redirection will be fast; eg, fast enough for 'needed for layout' objects. Each ServiceWorker is origin specific: they are not shared across domains, and they are completely isolated from the browser's HTTP cache [2]. I take this to imply that the ServiceWorker has no ability to provide persistent URLs to other origins. 4. De-duping file copies using a Git like scheme. == My sense is everyone likes the idea of avoiding storing redundant data and Git's use of the SHA1 message digest as the filename is 'good enough'. This is a low security risk mechanism that is good for storage efficiency. The most benefit occurs when the storage mechanism (eg, FileSystem, IndexedDB) applies this across origins. Like sharing across origins it gets the benefit of avoiding duplicates but it does not address the multiple downloads issue. Multiple downloads are probably okay for smallish files but could be an issue for larger files such as 20Mbyte Chinese fonts, large Javascript libraries, etc. My wild guess is that because this is a 'good thing to do' but not 'a critical thing to do', its odds of getting implemented are poor. Brian Stell Notes: [1] https://github.com/slightlyoff/ServiceWorker [2] https://github.com/slightlyoff/ServiceWorker/blob/master/caching.md On Wed, Nov 6, 2013 at 8:28 AM, pira...@gmail.com pira...@gmail.com wrote: That's very interesting and useful, but I don't think it fits the same use case I was talking about. I want the ability to create some object that exports an URL that I can put in an iframe. Then all requests from that iframe for resources will dynamically call my javascript code. I could implement the same logic that a server-side application does, but from local code in my browser. That's just the purpose of ServiceWorker :-) Only that from your message, I suspect you are asking about having the same functionality but only on the current session or maybe also only when the page is open, deleting it on reload. I don't know of anything like to this, the most similar ones would be FirefoxOS Browser API or Chrome FileSystem API, but nothing as powerful as ServiceWorker, sorry :-( They are talking about implementing the Fetch specification, maybe you would write them about allowing to be used someway the ServiceWorker functionality on a per-session basis, I find legitimate your proposition... -- Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes,
Re: Thoughts behind the Streams API ED
On Wed, Nov 6, 2013 at 7:33 PM, Aymeric Vitte vitteayme...@gmail.comwrote: I have seen the different bugs too, some comments: - maybe I have missed some explaination or some obvious thing but I don't understand very well right now the difference/use between readable/writablebytestream and bytestream ReadableByteStream and WritableByteStream are defining interfaces not only for ByteStream but more generally for other APIs. For example, we discussed how WebCrypto's encryption method should work with Stream concept recently, and one idea you showed was making WebCrypto.subtle return an object (which I called filter) to which we can pipe data. By defining a protocol how to pass data to consumer as the WritableByteStream interface, we can reuse it later for defining IDL for those filters. Similarly, ReadableByteStream can provide uniform protocol how data producing APIs should communicate with consumers. ByteStream is now a class inheriting both ReadableByteStream and WritableByteStream (sorry, I forgot to include inheritance info in the IDL). - pause/unpause: as far as I understand the whatwg spec does not recommend it but I don't understand the reasons. As I previously mentionned the idea is to INSERT a pause signal in the stream, you can not control the stream and therefore know when you are pausing it. Maybe after decoupling the interface, pause/unpause are things to be added to ByteStream? IIUC, pause prevents data from being read from a ByteStream, and unpause removes the dam? - stop/resume: same, see my previous post, the difference is that the consuming API should clone the state of the operation and close the current operation as if eof was received, then restart from the clone on resume Sorry that I haven't replied to your one. Your post about those methods: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0343.html WebCrypto ISSUE-22: http://www.w3.org/2012/webcrypto/track/issues/22 Maybe I still don't quite understand your ideas. Let me confirm. stop() tells the consumer API implementing WritableByteStream that it should behave as if it received EOF, but when resume() is called, restart processing the data written between stop() call and resume() call as if the API received data for the first time? How should stop() work for ByteStream? ByteStream's read() method will receive EOF at least once when all data written before stop() call has been read, and it keeps returning EOF until resume() tells the ByteStream to restart outputting? I've been feeling that your use case is very specific to WebCrypto. Saving state and restoring it sounds more like feature request for WebCrypto, not a Stream. But I'm a bit interested in what your stop()/resume() enables. With this feature, ByteStream becomes message stream which is convenient for handling WebSocket. - pipe []/fork: I don't see why the fast stream should wait for the slow one, so maybe the stream is forked and pause can be used for the slow one There could be apps that want to limit memory usage strictly. We think there're two strategies fork() can take. a) wait until the slowest substream consumes b) grow not to block the fastest substream while keeping data for the slowest a) is useful to limit memory usage. b) is more performance oriented. - flow control: could it be possible to advertise a maximum bandwidth rate for a stream? It's currently communicated as window similar to TCP. Consumer can adjust size argument of read() and frequency of read() call to match the consumer's processing speed.
Re: Define window.orientation
On Wed, 06 Nov 2013 01:17:31 +0100, Jonas Sicking jo...@sicking.cc wrote: window.screen.orientation seems like a better way forward. Why would window.screen.orientation be any more correctly implemented than window.orientation? -- Simon Pieters Opera Software
Re: Define window.orientation
Because it will be portrait or landscale and not numbers like 0, 90, ... which might start counting from portrait or landscape. Kenneth
Re: Define window.orientation
First off its unclear if they even have the same goal. Window.orientation seems to have been interpreted as zero means default orientation rather than zero means portrait. Unclear if that was the original intent or not. Second, it seems less likely that someone will misunderstand portrait to mean landscape than to misunderstand 0 to mean landscape. / Jonas On Nov 6, 2013 11:38 AM, Simon Pieters sim...@opera.com wrote: On Wed, 06 Nov 2013 01:17:31 +0100, Jonas Sicking jo...@sicking.cc wrote: window.screen.orientation seems like a better way forward. Why would window.screen.orientation be any more correctly implemented than window.orientation? -- Simon Pieters Opera Software
[Bug 22059] Composition dictionary should be changed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22059 Jianfeng Lin jianf...@microsoft.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from Jianfeng Lin jianf...@microsoft.com --- Thanks for accepting the proposal, Takayoshi. I saw that you put it right under InputMethodContext interface. Why not under the composition attribute of that interface? Since this is information about the composition, it makes more sense to be inside the composition attribute, and there you could simplify the name to be startOffset/endOffset, so developers can reference them by element.inputMethodContext.composition.startOffset. I'm still curious about the use cases for active segments. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 22093] Consider adding candidatewindowshow/update/hide events and getCandidateWindowClientRect()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22093 Jianfeng Lin jianf...@microsoft.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jianf...@microsoft.com Resolution|FIXED |--- --- Comment #9 from Jianfeng Lin jianf...@microsoft.com --- How about the isCandidateWindowVisible() in the proposal https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html#widl-InputMethodContext-isCandidateWindowVisible-boolean It's equivalent to having a candidatewindowshow event fired without a matching oncandidatewindowhide event, but can be queried at any time, whereas the event approach requires the developer to listen to the events and update the status in a variable. When the page is going to show some UI, the developer could call this function to see if the candidate window is visible, and if so, call getCandidateWindowClientRect() and position the UI away from the candidate window. -- You are receiving this mail because: You are on the CC list for the bug.
