Re: FileSystem compromise spec

On Fri, Nov 30, 2012 at 9:11 AM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
>> -----Original Message-----
>> From: Arthur Barstow [mailto:art.barstow@nokia.com]
>> Sent: Friday, November 30, 2012 6:46 AM
>> To: ext Eric U; Doug Schepers
>> Cc: Web Applications Working Group WG
>> Subject: Re: FileSystem compromise spec
>>
>> On 11/15/12 7:39 PM, ext Eric U wrote:
>> > As discussed at TPAC, there's little support for the current FileSystem API, but
>> > some support for a new API, and I promised to put forth a compromise proposal.
>> > In order to do that, I'd like to hear 1) what kinds of changes would make it
>> > more popular; 2) who I'm trying to convince.  There are a number of folks who
>> > have said that they're not interested in a FileSystem API at all, so I'd rather
>> > concentrate my efforts on those with skin in the game.
>> >
>
> Note that even though we are a service provider and not a browser vendor, I do consider us to have "skin in the game".

Sure thing; I was looking to hear from those who were interested, not
necessarily those who were implementers.

>> >    * It's designed to handle both the sandbox and the
>> >      outside-the-sandbox use cases.  For folks interested in just the sandbox and
>> >      no future expansions, that seems like wasted effort, and a sandbox-only API
>> >      could be simpler.  It's not clear to me that there is anyone interested in
>> >      just the sandbox and no future expansions, but if there is, please speak up.
>> >      I've certainly heard from folks with the opposite goal.
>
> I am still looking for evidence that IndexedDB provides a high-performance, scalable, cross-domain alternative to native filesystem access. I've seen conflicting information on that, and will gather this information with whatever tests can be found to validate performance of browsers for IndexedDB.

I've seen no proposals for cross-domain access.

>> It seems like it would be useful to look at these various file and
>> database specs from a high level use case perspective (f.ex. "one way to
>> address UC X is to use spec X"). If anyone is aware of some related
>> docs, please let me know. Doug - wondering aloud here if this is
>> something webplatform.org might cover or if you know of someone that
>> might be interested in creating this type of documentation?
>
> In the Web & TV IG I will be leading a task force specifically to address the recording and storage of media use cases, where storage options are the key focus. If someone can prove to us that "in-the-sandbox" storage addresses the needs (high-performance, scalable, cross-domain) then great; otherwise we will keep looking.

Isn't "in the sandbox" a bit opposed to "cross-domain"?  Or are you
suggesting some kind of a shared sandbox?

>> > I'd like to hear from folks who are interested, but not in the current spec.
>> >
>
> I note that this request seems to exclude (or recommend silence) of counter-points from those that *want the current specs* as mentioned by Eric. So if there is a lack of contribution from those that support the other use cases noted (e.g. out-of-the-sandbox storage), it should not be taken as consensus with the alternative as discussed in this thread.

That's because we took an informal poll at TPAC as to where folks
stood on these options:
	1) the current spec
	2) an evolution of the current spec to be more like the newer
proposals [the "compromise spec"]
	3) chuck it all and start over

...and not a single person present voted for option 1.  I'll count you
as 1, but there was a lot more support for 2 or 3.  I promised to make
a proposal for 2, and 3 needs at the very least an editor and a spec
to become viable.

I'm still hoping to hear who it is that's interested in 2, so that I
can make sure to address their concerns.  I wasn't at TPAC, so I don't
know who voted that way.

Received on Tuesday, 11 December 2012 21:44:30 UTC