Re: WebApps and SysApps Boundaries [Was: Re: Proposals received]

On Thu, Jan 10, 2013 at 7:37 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
>> From: Adam Barth <w3c@adambarth.com>
>> Date: Thu, 3 Jan 2013 11:47:33 -0800
>
>> It sounds like the next step here is for Wonsuk and me to talk with
>> the WebApps chairs to make sure we're not going to step on their toes
>> by issuing a call for consensus to publish Mounir's proposal as a
>> FPWD.
>
> Speaking as a WebApps Chair, I agree with Mike's opinion (as expressed in
> [1]) that SysApps should use its own list(s) for all of its specs and none
> of WebApps' lists should be used. I would even take it a bit further and
> recommend the groups' four Chairs enforce that separation (after all, WG
> charters include scope for good reasons including localizing IP concerns for
> Members).

That makes sense to me.  Given that the runtime is a SysApps
deliverable, it doesn't seem feasible to have the majority of the
discussion take place in another working group.

The SysApps charter asks that we seek feedback from the WebApps
working group on a deliverable once it enters Last Call.  If the
WebApps working group is amenable, we might seek feedback earlier than
Last Call to make sure the two working groups aren't working at cross
purposes.

> One possible exception is the application packaging format. WebApps does
> indeed have a related deliverable but as Mike noted, the scope of that spec
> is very narrow [3]. Based on a quick scan of Mounir's proposal [2], it
> appears SysApps' manifest spec today is intertwined with a lot of other
> features besides a packaging format (e.g. application management,
> application life cycle, updates, permissions, etc.). As such, I think the
> scope of the current spec is too broad for joint work with WebApps. However,
> if SysApps' packaging format was spit off to a separate more narrow spec
> that is closely aligned with WebApps' deliverable, it could make sense for
> the two groups to collaborate on that one feature.

The packaging format does seem like a separable concern from the other
aspects of the runtime (as you mention life cycle, updates,
permissions, etc).  The main dependency is that the other aspects
impose requirements on the packaging format (e.g., there needs to be a
slot to stuff the permissions into).  For that reason, it might be
easier to work with them in the same document, at least until the
requirements stabilize   We can always split out the packaging format
later if we decide that's the best thing to do.

Thanks!
Adam

Received on Friday, 11 January 2013 06:44:31 UTC