On Fri, Nov 30, 2012 at 9:11 AM, SULLIVAN, BRYAN L <[email protected]> wrote:
>> -----Original Message-----
>> From: Arthur Barstow [mailto:[email protected]]
>> 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.
