Re: FileSystem compromise spec

2012-12-11 Thread Eric U 
On Fri, Nov 30, 2012 at 9:11 AM, SULLIVAN, BRYAN L  wrote:
>> -Original Message-
>> From: Arthur Barstow [mailto:art.bars...@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.

RE: FileSystem compromise spec

2012-11-30 Thread SULLIVAN, BRYAN L 
> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@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".

> >* 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.

> 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.

> >
> > 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.

Thanks,
Bryan Sullivan

Re: FileSystem compromise spec

2012-11-30 Thread Arthur Barstow 

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.

So far I've been hearing:

   * It's too complicated.  A number of the methods aren't absolutely necessary
 if the user's willing to do a bit more work, so they should be dropped.
   * Even for what functionality we keep, it could be simpler.
   * The synchronous [worker-only] interface is superfluous.  It's not necessary
 for 1.0, and it's a lot of extra implementation work.
   * 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.

Does that sum it up?


That is a helpful summary so thanks for that.

Another at least somewhat related topic is the relationship between 
WebApps' File* specs and the file specs in scope for SysApps and Adam 
did a good job of clarifying that in 
.


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?


-Thanks, AB



I'd like to hear from folks who are interested, but not in the current spec.

Thanks,

Eric

FileSystem compromise spec

2012-11-15 Thread Eric U 
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.

So far I've been hearing:

  * It's too complicated.  A number of the methods aren't absolutely necessary
if the user's willing to do a bit more work, so they should be dropped.
  * Even for what functionality we keep, it could be simpler.
  * The synchronous [worker-only] interface is superfluous.  It's not necessary
for 1.0, and it's a lot of extra implementation work.
  * 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.

Does that sum it up?

I'd like to hear from folks who are interested, but not in the current spec.

Thanks,

Eric