RE: Updated charter proposal

I actually have been following the discussion and (think) I have a grasp on the context.

I support efforts to bridge the existing proposals through discussion in the group. Media storage is one of the key gaps in being able to support offline and cached use cases for stored media, as browser-based storage is ineffective for that (too large content). I also believe that the File API's security model is too manual (user-centric) but I support discussions about its use in a more persistent permission system, enabling persistent access to for example a "videos" storage location. Thus as a basis for the media storage API, it may have potential.

But overall, where there are existing APIs in development across multiple platforms (at least four I think), it seems to me there is clear market interest and the time is right for W3C to broker a standard from these.

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Adam Barth [mailto:w3c@adambarth.com] 
Sent: Sunday, June 03, 2012 8:30 AM
To: SULLIVAN, BRYAN L
Cc: public-sysapps@w3.org
Subject: Re: Updated charter proposal

That's a generous offer, but I don't think structuring the discussion
that way will help much in the immediate term.  I'm happy to
discussion the history of this issue off-list if you'd like to
understand more of the context.

Adam


On Sun, Jun 3, 2012 at 6:53 AM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
> I suggest if the common ground at this stage of the discussion may be that the Media Storage API could depend on the File API and its related APIs (for argument's sake, if those that think otherwise are willing to consider this), that we start with the assumption (if necessary, stated) that we will base APIs where possible on existing APIs of similar type (e.g. storage access). That would allow us to start the discussion of a specific Media Storage API, attempting to extend the File API ala whatever "depends upon" means, and not defer that discussion to some unspecified future date.
>
> As stated, we would be willing to contribute directly and co-edit if needed, regardless of the design approach that is pursued. So we are willing to get started on this API now.
>
> Thanks,
> Bryan Sullivan
>
> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Sunday, June 03, 2012 2:19 AM
> To: public-sysapps@w3.org
> Subject: Updated charter proposal
>
> Hi SysApps,
>
> Based on the discussion on this list, I've put together an updated
> proposal for a charter:
>
> http://abarth.github.com/websec/drafts/sysapps-charter.html
>
> In addition to fixing a couple typos, I've removed the term "browse-by
> web" as discussed in
> <http://lists.w3.org/Archives/Public/public-sysapps/2012May/0028.html>.
>  I've also re-worked the deliverables section a bit.  I've split the
> deliverables into two phases, as discussed in
> <http://lists.w3.org/Archives/Public/public-sysapps/2012May/0002.html>.
>  I've also added the following paragraph to explain the distinction
> between these phases:
>
> ---8<---
> The working group's deliverables are divided into two phases.
> Initially, the working group will focus on deliverables in the first
> phase in order to establish patterns and conventions that will be used
> for the remaining deliverables. The working group does not necessarily
> need to complete work on the phase 1 deliverables before working on
> deliverables in phase 2. However, the working group should make some
> substantial progress on some of the phase 1 deliverables before
> working on phase 2 deliverables.
> --->8---
>
> I was able to accomodate most of the requests folks sent to the list.
> The notable exceptions are Sensors, Calendar, and Contacts, all of
> which are deliverables for the Device APIs working group.  I'd like to
> avoid (or at least delay) a "territory" fight with that working group.
>  The charter has 16 deliverables, which is more than enough to keep us
> busy for two years.  I've also left NFC off the list because it had
> already been removed from the W3C version of the charter and seems
> likely to be taken up by the Near Field Communications working group.
>
> Despite strong interest on the mailing list, I've placed the Media
> Storage API in phase 2.  I think everyone agrees that Media Storage is
> an important API, but the issue is that there is strong disagreement
> about whether the API should depend on
> <http://www.w3.org/TR/file-system-api/>.  This working group will be
> the appropriate venue to have that discussion, but starting off with
> that discussion before we've all developed working relationships runs
> the risk of derailing the working group.  For that reason, I'd like to
> gather some momentum on some of the less contentious specs before
> opening that can of worms.
>
> Please let me know if you have any feedback.
>
> Many thanks,
> Adam
>

Received on Sunday, 3 June 2012 16:00:20 UTC