Re: App Manifest & API Proposal

Hi Anant,

On 14/05/2012 18:12, Anant Narayanan wrote:
> Hi Scott,
>
> Thanks for your comments, more inline.
>
> On 5/13/12 12:06 PM, Scott Wilson wrote:
>> On 12 May 2012, at 19:02, Anant Narayanan wrote:
>>> Q. Why not simply reuse the widgets spec [2]?
>>>
>>> A. Aside from naming (we're talking about apps, the word "widget" 
>>> seems to imply an artificial limitation),
>>
>> To be fair, you can call your implementation anything you want even 
>> if it implements the "Widget" specs. Maybe we could rename the Widget 
>> specs "Widgets, Apps, Gadgets or Whatever" specs.
>>
>> If you really, really hate the word that much you could decide to 
>> call the TWI widget object "app" instead in your own documentation, 
>> and just silently convert "window.widget" to "window.app" whenever 
>> you come across it. To reciprocate, I could add a line somewhere in 
>> Apache Wookie and Apache Cordova that does the exact opposite. 
>> Interoperability FTW!
>
> I'm trying to understand how building on the widget spec would work in 
> practice. I'm not opposed to it on principle, but we (Mozilla) have 
> chosen not to implement the widget spec in the past, but we have 
> already implemented the JSON manifest and API spec. If we rework this 
> proposal as an extension to the widget spec, does it mean we will have 
> to implement the entirety of the widget spec too?
Absolutely not: there would be no need to support the XML format. You 
just support a particular serialization (JSON) and not the packaging 
side (which is also orthogonal). But the semantics and data model remain 
the same across the specs where appropriate.
> Essentially, I'd like to make both spec independently implementable, 
> even if we chose to extend some objects defined in the widget spec.
Yes, that would be ideal. Historically, we renamed the Widget spec to 
"Packaging and *XML Configuration*" on purpose, because we've been 
anticipating the JSON format for a long long time (our requirement 
document has mentioned JSON as a target for many years [1]). We sat on 
it because we were waiting for Google or you guys to jump on it :)

Ideal situation: JSON format should be usable by UAs that currently 
support XML format (if there is support for that from implementers like 
Opera). If you guys have new/interesting use cases, then we should keep 
the specs in sync. I'm happy to help keep them in synchornized.
>>> and replacing XML with JSON;
>>
>> No objections to representing the manifest in JSON either. Would a 
>> serialization of The Widget Interface as a JSON manifest file obviate 
>> the need for defining basically the same metadata in a different 
>> spec? We can then just focus on the things that definitely aren't 
>> part of existing specs, such as the security model, installation 
>> events, and default orientation, all of which look like interesting 
>> extensions.
>
> Rich Tibbett from Opera did precisely that, you can see a mapping 
> here: 
> http://people.opera.com/richt/release/specs/manifests/widgets_to_app_manifest.html
>
> It looks good to me in general, but I'm a little wary of committing to 
> all fields that are valid keys in the XML schema. Is there a way we 
> can take a subset instead?
Absolutely! That would totally be ok. There is nothing required in the 
widget XML format at all. So, if you don't have a use case for something 
in the Widgets P&C spec, then you can simply ignore it. This is by design.

>>> the other fundamental difference is that the widget spec describes 
>>> packaged apps, whereas our manifest describes hosted apps.
>>
>> Widgets is also used for hosted as well as packaged apps e.g. Apache 
>> Wookie + Apache Rave...
>
> Ah, that's really good to know; I hadn't come across a widget that was 
> hosted before, but looks like it is possible.
There is a long legacy, dating back to the original Google Gadgets.
>>> We think hosted apps have several interesting and unique web-like 
>>> properties that are worth retaining. Hosted apps can be made to work 
>>> offline just as well as packaged apps with AppCache (which is in 
>>> need of some improvement, but can be made to work!).
>>
>> Which are the bits of this proposal that are important for this and 
>> which aren't found in Widgets? Can we add those to the existing specs 
>> to fill any gaps?
>
> The manifests in the proposal don't have an "id" field, because an app 
> is simply identified by the domain from which the manifest for it was 
> fetched. This is the key difference, but I'll have to look deeper at 
> the Widget spec to see if there are any more.

Looking forward to seeing what you find. And remember, we are open to 
changes so feel free to discuss.
>>> Packaged apps do have their own advantages though, which we 
>>> acknowledge, and are open to extending the spec to support both 
>>> types of apps.
>>
>> Hmm, that does kind of negate the previous point... but moving on..!
>
> We don't support packaged apps yet, either in the specification or the 
> implementation. If possible we'd like to go hosted + appcache as far 
> as we can. I mentioned this because I don't want packaged apps to be a 
> reason for this spec to be rejected.
I think that is fair.

>> I'm very positive about this proposal and would love to see it merged 
>> into Widgets:P&C & TWI, with perhaps a separate spec on web 
>> app/widget installation including the work Mozilla has done on 
>> installation APIs and events.
>
> I'm glad you like the proposal! However, I would really like to see 
> the API and manifest in the same document, because, as I mentioned 
> earlier, at-least in the context of browsers they are dependent on 
> each other. What does it mean for a browser to only "implement" the 
> manifest spec but not the installation API (or vice-versa)?
I'm really wondering the same thing. I'm not convinced the installation 
API is really needed if that part of the process is controlled 
internally by the UA (i.e., this is not something Web developers can 
access).
> On the other hand, there might be other User-Agents that won't have 
> the installation API though, because they don't have a DOM or support 
> JavaScript; in which case we could seperate them but write additional 
> text that recommends implementing both for environments that have a 
> DOM. I'm not sure if that's in scope for the working group.
For the reasons given above, my gut feeling is that it's not needed: 
application management should just be handled by the UA however it 
wants. I think we should spawn a new thread around this.

>> I'd be interested in implementing those in Apache Wookie, Apache Rave 
>> and related projects and initiatives that build on them, as web app 
>> installation and app store APIs are something thats come up in quite 
>> a few implementations and it would be great to have a spec for that.
>>
>> Just don't tie it to another competing manifest format, please!
>
> The current widget spec doesn't allow for a JSON representation.
Like I said above, we can just change the spec to allow it (if people 
want it) - it would take two seconds to add it (and we already discussed 
how this would work a bunch of times in the past: if JSON is present in 
package, use it... otherwise, fall back to XML). The point of specs is 
for them to be implemented, not to put roadblocks in the way for 
implementers. Nothing is set in stone, specially at this moment that 
"v1" of widgets is already a Rec... v2 is ready to go:
http://dev.w3.org/2006/waf/widgets/
> We will have to come up with a new specification for the JSON format 
> anyway, even if it is just a 1-1 mapping of the XML schema. While 
> we're at it, why not pare down on the field names we think are no 
> longer necessary, while adding the features that we think might be 
> useful to developers, users and stores?
By all means :)
>
> Essentially, I'm not fully understanding what the difference is 
> between merging into the Widgets spec as opposed to being a standalone 
> document. Both of them require implementation changes, new explanatory 
> text, test suites, etc.
Yes, we should not merge documents (that's really not necessary at all). 
Ideally, your spec would leverage whatever it can from the current 
widget specs (e.g., error recovery, default values, or just the 
semantics of things like description, version, etc.). And the XML 
dialect would separately deprecate/add whatever additional things are 
needed. In the end, whatever you can do with the JSON format, you should 
be able to do with the XML format. We would only do this iff current 
supporters of the XML format cared enough to also support the JSON 
format (otherwise, we just leave the XML format be as it has served it's 
purpose in many places over the last few years).

Hope that clarifies things.

[1] http://www.w3.org/TR/widgets-reqs/#format-and-schema

Received on Monday, 14 May 2012 22:14:36 UTC