Re: Polished FileSystem API proposal
On Mon, Jul 22, 2013 at 6:56 PM, Kinuko Yasuda wrote:
> On Tue, Jul 23, 2013 at 4:48 AM, Jonas Sicking wrote:
>>
>> On Mon, Jul 22, 2013 at 11:18 AM, Jan Varga wrote:
>> > On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking wrote:
>> >>
>> >> Hi All,
>> >>
>> >> Yesterday a few of us at mozilla went through the FileSystem API
>> >> proposal we previously sent [1] and tightened it up.
>> >>
>> >
>> > It was also pointed out that we should address multi-file locking too.
>> > One of the options is to make openRead() and openWrite() take a
>> > sequence.
>> >
>> > interface Directory {
>> > Promise openRead((DOMString or File) file);
>> > Promise openWrite((DOMString or File) file,
>> > OpenWriteOptions options);
>> > Promise> openRead(sequence<(DOMString or File)>
>> > files);
>> > Promise> openWrite(sequence<(DOMString or
>> > File)> files, OpenWriteOptions options);
>> > }
>> >
>> > So, this works with the current proposal, Jonas has a more complex
>> > solution
>> > that probably requires bigger changes in the proposed file system API.
>> > I'll let Jonas to describe it.
>>
>> First of all, I'm not sure that multi-file-locking is something that
>> we need to solve in this API at all. At least not yet. The google API
>> doesn't support locking of any type (as far as I can tell), so I think
>> starting with locking on a single-file basis is a better and simpler
>> place to start.
>>
>> The main concern I have with this approach is that it creates a very
>> specific API which solves a pretty narrow problem of copying data
>> between two files. It doesn't support copying data between a server
>> and a file, or between indexedDB and a file.
>>
>> I can think of two more generic solutions that will solve these problems:
>>
>> A) Adding something like inotify.
>> I.e. add the ability to get notifications about changes to part of a
>> filesystem. This way a page could create a lock-file when it wants to
>> prevent others from accessing a particular part of the filesystem.
>>
>> If the lockfile already exists, it could register to be notified when
>> the lockfile is removed. Once the file is removed it would create the
>> file and start accessing the files in whatever way it wants.
>>
>> This is how multi-process access to application data is often handled
>> in filesystems today.
>>
>> 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.
>>
>> B) Add a generic "cross-window lock" mechanism.
>>
>> Basically an API for asynchronously requesting a lock. Once the lock
>> becomes available the caller would be notified. When the caller is
>> done using the lock, he/she calls a function to explicitly release the
>> lock, thus enabling other callers to get notified that they are now
>> holding the lock.
>>
>> A lock is never automatically released by the platform on some timeout
>> or similar. The only time the lock is forcefully released is when the
>> user closes the page that created the lock.
>>
>> It is the application's responsibility to determine when it is
>> appropriate to grab the lock. I.e. there is no platform connection
>> between a lock and the resources that it protects. This way a lock
>> could represent anything from the whole filesystem, a couple of IDB
>> database and some server resources, to just parts of a file.
>>
>> Darin Fisher has proposed something similar in the past as I recall
>> it. Though the details might not exactly match the above.
>>
>>
>> Pros of A
>> - Solves more use cases than simply locking-related ones. We've
>> discussed adding similar observer mechanisms to IDB because the same
>> non-locking-related usecases have come up there.
>> - Enables building something like solution B on top of it.
>>
>> Cons of A
>> - More complicated to use correctly. For example it's important to
>> register for the notification before checking if the lock file is
>> already created. Otherwise there's a risk that the lock file is
>> removed between the time when the page checks if its there and the
>> notification is registered.
>>
>> Pros of B
>> - Easier to use than A
>>
>> Cons of B
>> - Doesn't help with use cases other than locking. I.e. to enable one
>> window to notice when another window modified some data, you would
>> either have to use polling, or create custom signaling mechanisms and
>> make sure to use those whenever something in the filesystem is
>> modified.
>
> I vote for B, it's more generic, simpler to use and can be implemented
> without dependency to the FileSystem API (thus it'd have higher probability
> to get implemented more quickly by multiple vendors).
>
> Separately from the locking issue, inotify-like feature (e.g. FileWatcher
> and DirectoryWatcher) has been also requested in Chrome
Re: Polished FileSystem API proposal
On Mon, Jul 22, 2013 at 3:40 PM, Janusz Majnert wrote: > 2013/7/22 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? FWIW in many other storage APIs, there has been an established need to enable observing modifications of that storage area. localStorage had this feature from the beginning. In IndexedDB discussions between Google and Mozilla determined that both had received requests for this. Not sure if Microsoft has received similar feedback. Even storage OS-level storage APIs, i.e. filesystems, generally have this functionality. So I think it makes a lot of sense to add it to this filesystem too. That said. I'm happy to punt on this for now. As long as we are ok with punting on support for multi-file locking. / Jonas
Re: Polished FileSystem API proposal
On Tue, Jul 23, 2013 at 4:48 AM, Jonas Sicking wrote:
> On Mon, Jul 22, 2013 at 11:18 AM, Jan Varga wrote:
> > On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking wrote:
> >>
> >> Hi All,
> >>
> >> Yesterday a few of us at mozilla went through the FileSystem API
> >> proposal we previously sent [1] and tightened it up.
> >>
> >
> > It was also pointed out that we should address multi-file locking too.
> > One of the options is to make openRead() and openWrite() take a sequence.
> >
> > interface Directory {
> > Promise openRead((DOMString or File) file);
> > Promise openWrite((DOMString or File) file,
> > OpenWriteOptions options);
> > Promise> openRead(sequence<(DOMString or File)>
> > files);
> > Promise> openWrite(sequence<(DOMString or
> > File)> files, OpenWriteOptions options);
> > }
> >
> > So, this works with the current proposal, Jonas has a more complex
> solution
> > that probably requires bigger changes in the proposed file system API.
> > I'll let Jonas to describe it.
>
> First of all, I'm not sure that multi-file-locking is something that
> we need to solve in this API at all. At least not yet. The google API
> doesn't support locking of any type (as far as I can tell), so I think
> starting with locking on a single-file basis is a better and simpler
> place to start.
>
> The main concern I have with this approach is that it creates a very
> specific API which solves a pretty narrow problem of copying data
> between two files. It doesn't support copying data between a server
> and a file, or between indexedDB and a file.
>
> I can think of two more generic solutions that will solve these problems:
>
> A) Adding something like inotify.
> I.e. add the ability to get notifications about changes to part of a
> filesystem. This way a page could create a lock-file when it wants to
> prevent others from accessing a particular part of the filesystem.
>
> If the lockfile already exists, it could register to be notified when
> the lockfile is removed. Once the file is removed it would create the
> file and start accessing the files in whatever way it wants.
>
> This is how multi-process access to application data is often handled
> in filesystems today.
>
> 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.
>
> B) Add a generic "cross-window lock" mechanism.
>
> Basically an API for asynchronously requesting a lock. Once the lock
> becomes available the caller would be notified. When the caller is
> done using the lock, he/she calls a function to explicitly release the
> lock, thus enabling other callers to get notified that they are now
> holding the lock.
>
> A lock is never automatically released by the platform on some timeout
> or similar. The only time the lock is forcefully released is when the
> user closes the page that created the lock.
>
> It is the application's responsibility to determine when it is
> appropriate to grab the lock. I.e. there is no platform connection
> between a lock and the resources that it protects. This way a lock
> could represent anything from the whole filesystem, a couple of IDB
> database and some server resources, to just parts of a file.
>
> Darin Fisher has proposed something similar in the past as I recall
> it. Though the details might not exactly match the above.
>
>
> Pros of A
> - Solves more use cases than simply locking-related ones. We've
> discussed adding similar observer mechanisms to IDB because the same
> non-locking-related usecases have come up there.
> - Enables building something like solution B on top of it.
>
> Cons of A
> - More complicated to use correctly. For example it's important to
> register for the notification before checking if the lock file is
> already created. Otherwise there's a risk that the lock file is
> removed between the time when the page checks if its there and the
> notification is registered.
>
> Pros of B
> - Easier to use than A
>
> Cons of B
> - Doesn't help with use cases other than locking. I.e. to enable one
> window to notice when another window modified some data, you would
> either have to use polling, or create custom signaling mechanisms and
> make sure to use those whenever something in the filesystem is
> modified.
I vote for B, it's more generic, simpler to use and can be implemented
without dependency to the FileSystem API (thus it'd have higher probability
to get implemented more quickly by multiple vendors).
Separately from the locking issue, inotify-like feature (e.g. FileWatcher
and DirectoryWatcher) has been also requested in Chrome version's FS API,
and I can imagine the feature would get some popularity. But my personal
feeling is it might be too rich for 'simple' sandboxed file-storage API (at
least for
Re: Web Widgets, Where Art Thou?
On Mon, Jul 22, 2013 at 11:55 PM, Charles McCathie Nevile <
cha...@yandex-team.ru> wrote:
> On Mon, 22 Jul 2013 09:59:33 -0700, Daniel Buchner
> wrote:
>
> In my opinion, the current spec's complexity in relation to its feature
>> goal, is high.
>>
>
> I think it is pretty important to this discussion to understand what parts
> of the widget framework you think bring complexity (or alternatively, bring
> little value).
>
> Different people interpret complexity very differently. For example there
> are many developers today who find JSON extremely comfortable and flexible.
> But others find it extremely limited (no common internationalisation
> mechanism, the strictness of the syntax is almost invisible being expressed
> only in tiny punctuation marks, no clear comment mechanism, ...)
>
> Without a clear idea of what you mean by complexity (or clarity) it is
> very hard to understand what your statement means, and therefore what
> should be changed...
>
To clarify, I am proposing that we make a simple app manifest entry the
only requirement for widget declaration: *widget: { launch_path: ... }*.
The issue with *viewMode *(https://github.com/w3c/manifest/issues/22), is
that it hard-binds a widget's launch URL to the app's launch URL, forever
tying the widget to the "full app". I'd like to give devs the option to
provide a completely different launch path for widgets, if they choose. As
for the finer points of widget declaration, why force developers to
generate two separate files that regurgitate much of the same information?
--> this looks a lot more complex than adding a launch path to an existing
file and a few media queries for styling:
http://www.w3.org/TR/2009/WD-widgets-reqs-20090430/
> while taking advantage of natural synergies that result from reusing
>> a common base.
>>
>
> I think I agree, but can we be explicit about the things we think we're
> getting?
>
Many mobile apps include widgets, and users are beginning to think: "Hey, I
wonder if this app has a widget?"; some users even seek out apps that
provide a companion widget in addition to the app itself. Using an app
manifest for packaging is easier on developers, and aligns with user
perception of the output.
> For example, many browsers now use some form of JSON to write a manifest
> that (other than the syntax) is almost identical to the XML packaging used
> for widgets. And as JC noted there are actually numerous systems using the
> XML Packaging and Configuration.
>
> I see widgets as a web page (perhaps the same page as a "full" app,if the
>> dev chooses) with near-zero additional, cognitive overhead.
>>
>
> I'm afraid I have no idea what this means in practice.
I was referring to the choice (detailed above) a developer has to use the
app launch path, or an different URL, as their widget path, and to do so
via a common declaration vehicle. That simplifies the declaration side. On
the code side, I would stay away from adding any mechanisms (other than
display helpers, like widget-specific media queries) to the widget context
- the message: just use the same APIs you would use for any other app/page.
With today's web, are these APIs really necessary? -->
http://www.w3.org/TR/widgets-apis/
> Declaration via the app manifest is a huge piece - I'd argue that
> this alone would realize a huge increase in developer utilization.
>
I suspect this is a very common perception.
>
> Let's look at current consumer perception of widgets, and how the space
>> is evolving:
>>
>>- Widgets are commonplace on mobile platforms
>>- In the view of consumers, search, discovery, and purchase/
>>
> installation of widgets is now distinguishable from apps
>
> Do you mean "indistinguishable"?
>
I did, sorry about that :)
- I believe we should retool efforts in this area to focus on sharing
>> the app packaging vehicle and reducing complexity to near-zero (besides
>> things like widget-specific media queries)
>>
>
> This is where it is critical to know what you think is "near-zero
> complexity". Having seen a couple of systems deployed based on JSON
> packaging (Google and Mozilla), and a bunch of them based on the current
> XML Widget Packaging, I personally find the latter far less complex. But I
> realise not everyone thinks like I do.
>
If you asked the average client-side web developer, who lives primarily in
HTML, CSS, and JS, I would bet a trillion dollar coin that the *overwhelming
* majority prefer JSON for description, packaging, and data transmission -
consider: web app manifests, NPM, Bower, and nearly every client-consumed
web-service API launched in the last 4 years.
Re: Polished FileSystem API proposal
2013/7/22 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: Web Widgets, Where Art Thou?
On Mon, 22 Jul 2013 09:59:33 -0700, Daniel Buchner wrote: In my opinion, the current spec's complexity in relation to its feature goal, is high. I think it is pretty important to this discussion to understand what parts of the widget framework you think bring complexity (or alternatively, bring little value). Different people interpret complexity very differently. For example there are many developers today who find JSON extremely comfortable and flexible. But others find it extremely limited (no common internationalisation mechanism, the strictness of the syntax is almost invisible being expressed only in tiny punctuation marks, no clear comment mechanism, …) Without a clear idea of what you mean by complexity (or clarity) it is very hard to understand what your statement means, and therefore what should be changed... [...] I'd like to step back and formulate a strategy based on the progression and growing prevalence of widgets on native mobile platforms, Presumably unsurprisingly, this was part of the approach that led to the current family of Widget specs. as well as how we can align widgets with the packaging and distribution of web apps. Yes, this is important. The paradigm of declaring/packaging widgets inside app packages is a beneficial pairing that reduces the amount of code and management developers are forced to think about, Yes... while taking advantage of natural synergies that result from reusing a common base. I think I agree, but can we be explicit about the things we think we're getting? For example, many browsers now use some form of JSON to write a manifest that (other than the syntax) is almost identical to the XML packaging used for widgets. And as JC noted there are actually numerous systems using the XML Packaging and Configuration. I see widgets as a web page (perhaps the same page as a "full" app,if the dev chooses) with near-zero additional, cognitive overhead. I'm afraid I have no idea what this means in practice. Declaration via the app manifest is a huge piece - I'd argue that this alone would realize a huge increase in developer utilization. I suspect this is a very common perception. Let's look at current consumer perception of widgets, and how the space is evolving: - Widgets are commonplace on mobile platforms - In the view of consumers, search, discovery, and purchase/ installation of widgets is now distinguishable from apps Do you mean "indistinguishable"? - Widgets remain a feature used primarily by savvy users, but new presentations will blur the lines between what a widget is - let's get ahead of this! The last point here is important for the next generation of 'widgets'. Widgets in the "statically-present-on-a-home-screen" incarnation are currently the most recognizable form, but this is changing. Look at Google Now - those cards, they're just widgets IMO. Yes, and likewise Yandex Islands - and yandex Widgets. And Opera's "Speed Dial Extensions". In the early days of widgets there also a lot of things like Yandex widgets - ways to collect bits of web content onto a page that was put together server-side. That paradigm hasn't disappeared, although I think it is fair to say that widgets arenow more familiar to users as stand-alone apps. Conclusions: - If users no longer distinguish between apps and widgets in practice, a common packaging vehicle makes sense. Yes. - We are seeing proactive, contextual presentation of data in widget-esque forms on Android and iOS (Moto X looks like it will introduce more of this). Under the proposed direction of widgets, developers need only know what context their widget is being evoked in, and how best to layout a UI for the intended display. (media queries for something like "blocks" - just an example, you get the idea) - I believe we should retool efforts in this area to focus on sharing the app packaging vehicle and reducing complexity to near-zero (besides things like widget-specific media queries) This is where it is critical to know what you think is "near-zero complexity". Having seen a couple of systems deployed based on JSON packaging (Google and Mozilla), and a bunch of them based on the current XML Widget Packaging, I personally find the latter far less complex. But I realise not everyone thinks like I do. - If we want to make a splash, actively encourage implementers to add features based on widgets or widgets + apps (this is a feature we've discussed for future enhancement of the Firefox desktop experience) This sounds a bit like partying like it is 2009. I'm sure with a marketing budget people can make a splash of that, but it seems more like catching up to me. Which means we should do it primarily to promote interoperability with the systems that are several years in f
Re: Web Widgets, Where Art Thou?
Hi Daniel, On Monday, 22 July 2013 at 17:59, Daniel Buchner wrote: > In my opinion, the current spec's complexity in relation to its feature goal, > is high. I'm not sure what this means, to be honest. The engines that have used widgets always managed to do it without significant problems and seem to be fit for purpose (in the way's they use the capabilities afforded by the format) - I'm of course, extremely bias as I wrote the things and was directly involved with many projects using widgets. Regardless, for example, Opera's Extension platform successfully used widgets and related technologies without significant problems (it was then abandoned in the switch to Blink, as Opera is now able to cleverly leverage Chrome's extension platform). Also, WAC's runtimes made use of widget's element to enable APIs without any problems, AFAIK (see http://specs.wacapps.net/). > This doesn't mean it was a bad spec or deficient, it could be due to a number > of factors: different assumptions about what widgets should do, packaging > choices that existed before web apps gained steam, or a different focus on > where and how widgets would be displayed. In the case of WAC, I think it was just poor execution (compared to, say, FirefoxOS and the great developer drive behind it … again, I'm bias because I work for Moz also ^_^). Opera Extensions were quite successful as a platform and served Opera's users well, IM-Biased-O. Anyway, I could rant for hours about how different *product management* choices affect the uptake of widget technologies :) > I'd like to step back and formulate a strategy based on the progression and > growing prevalence of widgets on native mobile platforms, as well as how we > can align widgets with the packaging and distribution of web apps. This is basically what we are doing with: http://www.w3.org/2012/sysapps/manifest/ > The paradigm of declaring/packaging widgets inside app packages is a > beneficial pairing that reduces the amount of code and management developers > are forced to think about, while taking advantage of natural synergies that > result from reusing a common base. I see widgets as a web page (perhaps the > same page as a "full" app, if the dev chooses) with near-zero additional, > cognitive overhead. Declaration via the app manifest is a huge piece - I'd > argue that this alone would realize a huge increase in developer utilization. Historically, this has not been the case however. Web apps are significantly different beasts to the experience provided by a packaged application: packaged apps offer a more tradition software experience, while web apps generally work better as services (… someone should try to do a PhD about this… oh, wait! that poor fool was me :) ). > Let's look at current consumer perception of widgets, and how the space is > evolving: > Widgets are commonplace on mobile platforms true. > In the view of consumers, search, discovery, and purchase/installation of > widgets is now distinguishable from apps true (in some stores). > Widgets remain a feature used primarily by savvy users, but new presentations > will blur the lines between what a widget is - let's get ahead of this! Sure: this was the intention of the view mode media feature. > The last point here is important for the next generation of 'widgets'. > Widgets in the "statically-present-on-a-home-screen" incarnation are > currently the most recognizable form, but this is changing. Look at Google > Now - those cards, they're just widgets IMO. Sure, or they could just be iframes. Point is, there is more than one way to skin this cat: the use case is more important than what technology is used to address the use case. > Conclusions: > If users no longer distinguish between apps and widgets in practice, a common > packaging vehicle makes sense. I believe we have this covered by the suite of specifications already available. For those that want packaged web apps "today", they can use: "Packaged Web Apps (Widgets) - Packaging and XML Configuration" - http://www.w3.org/TR/widgets/ For those that want to "install" web pages (or have an allergic reaction to XML), the Web Manifest format is under development: http://www.w3.org/2012/sysapps/manifest/ And for those that have an allergy to XML, but want things in a zip file - the SysApps runtime and security model spec has that covered: http://runtime.sysapps.org/ > We are seeing proactive, contextual presentation of data in widget-esque > forms on Android and iOS (Moto X looks like it will introduce more of this). > Under the proposed direction of widgets, developers need only know what > context their widget is being evoked in, and how best to layout a UI for the > intended display. (media queries for something like "blocks" - just an > example, you get the idea) > I believe we should retool efforts in this area to focus on sharing the app > packaging vehicle and reducing c
Re: Polished FileSystem API proposal
> 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
Re: Polished FileSystem API proposal
On Mon, Jul 22, 2013 at 11:18 AM, Jan Varga wrote:
> On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking wrote:
>>
>> Hi All,
>>
>> Yesterday a few of us at mozilla went through the FileSystem API
>> proposal we previously sent [1] and tightened it up.
>>
>
> It was also pointed out that we should address multi-file locking too.
> One of the options is to make openRead() and openWrite() take a sequence.
>
> interface Directory {
> Promise openRead((DOMString or File) file);
> Promise openWrite((DOMString or File) file,
> OpenWriteOptions options);
> Promise> openRead(sequence<(DOMString or File)>
> files);
> Promise> openWrite(sequence<(DOMString or
> File)> files, OpenWriteOptions options);
> }
>
> So, this works with the current proposal, Jonas has a more complex solution
> that probably requires bigger changes in the proposed file system API.
> I'll let Jonas to describe it.
First of all, I'm not sure that multi-file-locking is something that
we need to solve in this API at all. At least not yet. The google API
doesn't support locking of any type (as far as I can tell), so I think
starting with locking on a single-file basis is a better and simpler
place to start.
The main concern I have with this approach is that it creates a very
specific API which solves a pretty narrow problem of copying data
between two files. It doesn't support copying data between a server
and a file, or between indexedDB and a file.
I can think of two more generic solutions that will solve these problems:
A) Adding something like inotify.
I.e. add the ability to get notifications about changes to part of a
filesystem. This way a page could create a lock-file when it wants to
prevent others from accessing a particular part of the filesystem.
If the lockfile already exists, it could register to be notified when
the lockfile is removed. Once the file is removed it would create the
file and start accessing the files in whatever way it wants.
This is how multi-process access to application data is often handled
in filesystems today.
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.
B) Add a generic "cross-window lock" mechanism.
Basically an API for asynchronously requesting a lock. Once the lock
becomes available the caller would be notified. When the caller is
done using the lock, he/she calls a function to explicitly release the
lock, thus enabling other callers to get notified that they are now
holding the lock.
A lock is never automatically released by the platform on some timeout
or similar. The only time the lock is forcefully released is when the
user closes the page that created the lock.
It is the application's responsibility to determine when it is
appropriate to grab the lock. I.e. there is no platform connection
between a lock and the resources that it protects. This way a lock
could represent anything from the whole filesystem, a couple of IDB
database and some server resources, to just parts of a file.
Darin Fisher has proposed something similar in the past as I recall
it. Though the details might not exactly match the above.
Pros of A
- Solves more use cases than simply locking-related ones. We've
discussed adding similar observer mechanisms to IDB because the same
non-locking-related usecases have come up there.
- Enables building something like solution B on top of it.
Cons of A
- More complicated to use correctly. For example it's important to
register for the notification before checking if the lock file is
already created. Otherwise there's a risk that the lock file is
removed between the time when the page checks if its there and the
notification is registered.
Pros of B
- Easier to use than A
Cons of B
- Doesn't help with use cases other than locking. I.e. to enable one
window to notice when another window modified some data, you would
either have to use polling, or create custom signaling mechanisms and
make sure to use those whenever something in the filesystem is
modified.
/ Jonas
[Bug 22754] " width:100%; height:100%;"
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22754 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.
Re: Polished FileSystem API proposal
And here's an example:
// Copy the 1th byte of file1.bin to file2.bin
navigator.getFilesystem().then(function(root) {
return root.openWrite(["file1.bin", "file2.bin"]);
}).then(function(handles) {
return handles[0].read(1);
}).then(function(buffer) {
return handles[1].write(buffer);
});
On Mon, Jul 22, 2013 at 8:18 PM, Jan Varga wrote:
> On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking wrote:
>
>> Hi All,
>>
>> Yesterday a few of us at mozilla went through the FileSystem API
>> proposal we previously sent [1] and tightened it up.
>>
>>
> It was also pointed out that we should address multi-file locking too.
> One of the options is to make openRead() and openWrite() take a sequence.
>
> interface Directory {
> Promise openRead((DOMString or File) file);
>Promise openWrite((DOMString or File) file,
> OpenWriteOptions options);
> Promise> openRead(sequence<(DOMString or File)>
> files);
> Promise> openWrite(sequence<(DOMString or
> File)> files, OpenWriteOptions options);
> }
>
> So, this works with the current proposal, Jonas has a more complex
> solution that probably requires bigger changes in the proposed file system
> API.
> I'll let Jonas to describe it.
>
> Jan
>
>
Re: Polished FileSystem API proposal
On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking wrote:
> Hi All,
>
> Yesterday a few of us at mozilla went through the FileSystem API
> proposal we previously sent [1] and tightened it up.
>
>
It was also pointed out that we should address multi-file locking too.
One of the options is to make openRead() and openWrite() take a sequence.
interface Directory {
Promise openRead((DOMString or File) file);
Promise openWrite((DOMString or File) file,
OpenWriteOptions options);
Promise> openRead(sequence<(DOMString or File)>
files);
Promise> openWrite(sequence<(DOMString or
File)> files, OpenWriteOptions options);
}
So, this works with the current proposal, Jonas has a more complex solution
that probably requires bigger changes in the proposed file system API.
I'll let Jonas to describe it.
Jan
[Bug 22754] New: " width:100%; height:100%;"
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22754 Bug ID: 22754 Summary: " width:100%; height:100%;" Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Fullscreen Assignee: ann...@annevk.nl Reporter: fal...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://fullscreen.spec.whatwg.org/#user-agent-level-style-sheet-defaults [[ width:100%; height:100%; ]] Are these redundant since there is already top:0; right:0; bottom:0; left:0; -- You are receiving this mail because: You are on the CC list for the bug.
Re: Web Widgets, Where Art Thou?
In my opinion, the current spec's complexity in relation to its feature goal, is high. This doesn't mean it was a bad spec or deficient, it could be due to a number of factors: different assumptions about what widgets should do, packaging choices that existed before web apps gained steam, or a different focus on where and how widgets would be displayed. I'd like to step back and formulate a strategy based on the progression and growing prevalence of widgets on native mobile platforms, as well as how we can align widgets with the packaging and distribution of web apps. The paradigm of declaring/packaging widgets inside app packages is a beneficial pairing that reduces the amount of code and management developers are forced to think about, while taking advantage of natural synergies that result from reusing a common base. I see widgets as a web page (perhaps the same page as a "full" app, if the dev chooses) with near-zero additional, cognitive overhead. Declaration via the app manifest is a huge piece - I'd argue that this alone would realize a huge increase in developer utilization. Let's look at current consumer perception of widgets, and how the space is evolving: - Widgets are commonplace on mobile platforms - In the view of consumers, search, discovery, and purchase/installation of widgets is now distinguishable from apps - Widgets remain a feature used primarily by savvy users, but new presentations will blur the lines between what a widget is - let's get ahead of this! The last point here is important for the next generation of 'widgets'. Widgets in the "statically-present-on-a-home-screen" incarnation are currently the most recognizable form, but this is changing. Look at Google Now - those cards, they're just widgets IMO. Conclusions: - If users no longer distinguish between apps and widgets in practice, a common packaging vehicle makes sense. - We are seeing proactive, contextual presentation of data in widget-esque forms on Android and iOS (Moto X looks like it will introduce more of this). Under the proposed direction of widgets, developers need only know what context their widget is being evoked in, and how best to layout a UI for the intended display. (media queries for something like "blocks" - just an example, you get the idea) - I believe we should retool efforts in this area to focus on sharing the app packaging vehicle and reducing complexity to near-zero (besides things like widget-specific media queries) - If we want to make a splash, actively encourage implementers to add features based on widgets or widgets + apps (this is a feature we've discussed for future enhancement of the Firefox desktop experience) I'd like to hear any additional feedback, and your thoughts on next steps.
Re: Web Widgets, Where Art Thou?
On Monday, July 22, 2013 at 9:16 AM, JC Verdié wrote: > Hi Daniel > > While widgets were (unfortunately) not widely adopted, a few companies > (including mine) are using it and it does the job for many simple > issues. It's true that the complexity of the spec vs the service > provided was not really a good deal. As editor, I'm interested about the complexity aspect of widgets (aside from digital signatures, what other complexities have been faced?). Can you provide some more details about that? Obviously, we want to avoid similar issues with the packaged apps and hosted apps efforts. >
Re: Web Widgets, Where Art Thou?
Hi Daniel While widgets were (unfortunately) not widely adopted, a few companies (including mine) are using it and it does the job for many simple issues. It's true that the complexity of the spec vs the service provided was not really a good deal. However, what you describe makes sense. I know there are other members who have been pushing a lot in the past to keep widgets alive. May be they'll also pop in. Regards JC Daniel Buchner wrote: As some of you are aware, a widget spec or two (http://www.w3.org/TR/2012/PR-widgets-apis-20120522/) have been floating around for a while. These were never widely adopted for various reasons - not the least of which was their complexity. Well, hold on to your shorts folks: I would like to rekindle the idea of web widgets, but with an eye toward simplicity that builds on open web app concepts and mechanism. My proposal is simple: Widgets are just an alternate (or even the same) app 'launch_path' a developer would declared under a 'widget' key in their existing App Manifest. The UA would launch this URL in whatever widget UI containers it creates, for example: squares on a New Tab, a floating panel, etc., and add a few things to the document context - namely: an imperative means for detecting the document is being displayed in a widget state, and a new media query type 'widget' for styling (especially helpful if the developers chooses to use a single origin for their app and widget) What this allows for: - Let's us utilize the existing declaration and installation mechanisms for web apps (which is the same place widgets are already declared in today's common native app packages) - Provides a great new variant of content for all UAs who already are implementing apps - Delivers huge user benefit at a relatively low cost "Stupid-Simple Web Widgets: great idea, or greatest idea?...I'm gonna put you down for great." - /PS - If the word 'widget' makes you feel dirty and sad-faced (which it shouldn't, as Android proved and iOS concurred), let's just imagine we're talking about the W3 Web Dingus spec for now and focus on the user value proposition ;) /
