Re: joint work with WebApps WG on Manifest

On Thu, May 9, 2013 at 6:40 PM, Charles McCathie Nevile
<chaals@yandex-team.ru> wrote:
> On Sat, 27 Apr 2013 01:40:32 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Fri, Apr 26, 2013 at 9:58 AM, Wonsuk Lee <wonsuk73@gmail.com> wrote:
>>>
>>> 2013/4/26 Dave Raggett <dsr@w3.org>
>>>>
>>>>
>>>> This to bring an issue [1] to the full SysApps WG mailing list.
>>>> The SysApps and WebApps working groups both have an interest in
>>>> standardizing a JSON based manifest format for apps.
>>>>
>>>> The requirements for manifests for packaged and hosted apps overlap
>>>> significantly, and presumably app developers would like to minimise
>>>> differences in the manifest formats for packaged and hosted apps.
>>>>
>>>> This has been discussed at the recent SysApps Face to Face meeting [2],
>>>> and separately by WebApps [3].
>>>>
>>>> Here are some possibilities:
>>>>
>>>> a. one of the two groups takes full ownership of the
>>>>    manifest format for both packaged and hosted apps
>>>>
>>>> b. one group standardizes the manifest format and the
>>>>    other group standardizes extensions to that format
>>>>    as necessary for their own use cases
>>>>
>>>> c. there is a joint task force involving both groups
>>>>    that standardizes a single specification covering
>>>>    the use cases for both working groups
>>>
>>>
>>>
>>> When I had a discussion in web apps wg in yesterday, Mike(W3C) raised
>>> issue about administrative issue. So I have type "b" in mind. but I
>>> would like to get feedback from the group members
>
>
> As a Webapps co-chair and group member in sysapps...
>
>
>> Yup. I like this approach the best. Having the WebApps WG standardize
>> the manifest format and have the discussions about it happen on the
>> main webapps mailing list has the advantage that we're more likely to
>> get input from a broad range of browser vendors, which should maximize
>> the chance of quick adoption by implementations.
>>
>> Having broad adoption by browser vendors I think is the best way to
>> get broad adoption by websites. This lowers the barrier for websites
>> to also adopt the runtime spec if they already have a manifest. In
>> fact, in many cases simply submitting the URL of that manifest to a
>> store is all that an author would need to do. Stores could even
>> automatically find manifests through spidering.
>
>
> Yep yep yep. Actually I think it will be interesting to talk to the
> onepf.org guys at Yandex who are working in a community project on a
> single manifest for Android apps to submit to the various different
> Android app stores.
>
>
>> Meanwhile the sysapps group can focus on adding the extensions that we
>> need in order to enable app developers that want to create more
>> powerful apps. So for example I would imagine that the "permissions"
>> property is something that I think we'd have to handle.
>
>
> Given that it seems to be just a JSON-isation of the feature element in
> the widgets stuff, I don't see why it is a big deal. Webapps has a
> recommendation that does the same thing already, and has major content
> producers who would like to see semantic consistency between the widgets
> platform and the JSON-isation.
>
>>>> [...] it seems that WebApps WG is willing to take on full ownership
>>>>
>>>> and to drive the spec to W3C Recommendation for both packaged and hosted
>>>> apps.
>>>>
>>>> Presumably, this includes covering any SysApps requirements in relation
>>>> to the security and runtime model.
>>>>
>>>
>>> I am not sure Web apps WG is willing to make manifest specs including
>>> packaged web app. I understood as Web Apps handle only for part related
>>> with hosted web app and SysApps WG do take care of parts of packaged
>>> web app. Jonas, Could you add more comment on this?
>>
>>
>> Agreed. I don't think that the webapps working group is interested in
>> taking on packaged or signed apps at this time.
>
>
> We have a Recommendation for packaged apps already, and as I understood
> the discussion at the meeting we were pretty clear that this is part of
> what we do. Your app: URI spec is just a copy and paste of the Widget URI
> work done in webapps, with s/widget/app/g (and then some nice editing by
> Marcos to make it not look quite the same - but seriously, when the first
> CfC went out the examples were identical down to having the same UUID). We
> have a spec for signing apps which was held up by a PAG for a year or two,
> but is now back on track to be shipped as a Recommendation.
>
> I see no reason why you wouldn't leave this to Webapps, who have done it
> once already, and concentrate on the actual APIs, which are potentially
> quite complex and will require some serious expertise gathering to get
> right.
>
> On the other hand, the Webapps group explicitly rejected the runtime
> aspect (which was recently split into a separate spec) despite the fact
> that it is in their current charter. This is another item that I think
> will take some serious work and hope that the sysapps groups can focus on.

Chaals, this seems like an argument that we should do more of the work
in the WebApps group because it fits within the groups charter.

However I don't think the most important question is if it's covered
by the existing charter or not. The more important question is if the
group collectively wants to take on these specs.

The sense that I got at the face-to-face was that the group was not
interested. If that's the cast I don't think charter questions really
matter.

(That said, I do agree with you and think that it does fit within the
current charter).

/ Jonas

Received on Sunday, 12 May 2013 02:29:52 UTC