W3C home > Mailing lists > Public > public-sysapps@w3.org > May 2013

Re: joint work with WebApps WG on Manifest

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 12 May 2013 13:15:33 -0700
Message-ID: <CA+c2ei_SEmiV+noR-4Bx3fjrJtox1wp+zMW1q6zKETzzrhg9cg@mail.gmail.com>
To: Charles McCathie Nevile <chaals@yandex-team.ru>
Cc: "public-sysapps@w3.org" <public-sysapps@w3.org>, Arthur Barstow <art.barstow@nokia.com>
On Sun, May 12, 2013 at 6:34 AM, Charles McCathie Nevile
<chaals@yandex-team.ru> wrote:
> On Sun, 12 May 2013 03:28:54 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Thu, May 9, 2013 at 6:40 PM, Charles McCathie Nevile
>>>
>>> On Sat, 27 Apr 2013 01:40:32 +0200, Jonas Sicking <jonas@sicking.cc>
>
>
>>>> 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.
>>>>>>
>>>>> 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.
>
>
>>>> 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.... 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.
>
>
> Actually, has been, as Marcos reminded me.
>
>
>>> 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.
>
>
> Agreed.
>
>
>> 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.
>
> My sense was that they are happy to take the manifest, and bought your
> argument that the same manifest with some tweaks applies to hosted and
> packaged apps.
>
> We have had a number of people in webapps say that they want to support
> packaged apps, and even that they want to keep the semantic correspondence
> with the widget stack where possible.
>
> As I said elsewhere in the thread, if the app-uri meets your goals now, I
> think there is a strong argument for taking up the widget: work with a new
> name for the scheme, and finishing it. This could be done in a few weeks -
> there has been implementation already. A change of name is about the most
> trivial change that might affect implementations, so if say Tizen or
> Blackberry are interested in using app: I would expect Candidate
> Recommendation to be zero-length...

I actually wouldn't want the app:// protocol to go to CR that quickly.
I think there are a number of tricky issues, such as origins, that
goes hand-in-hand with the security model and with the runtime spec.
So I think the app:// protocol should be developed in the same WG and
on the same mailing list as the runtime and security specs.

I've personally given up on making that be the webapps list right now.

/ Jonas
Received on Sunday, 12 May 2013 20:16:31 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 16:04:43 UTC