Re: App Manifest & API Proposal

On 14 May 2012, at 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?

"Entirety of the widget spec" isn't much - you've done most of it already. If you mean would you have to support an XML manifest, or support packaged apps as well as "naked" manifests? No, I can't see a reason you would.

Comparing TWI with the proposal, the only things in TWI that are additional are shortName, authorEmail, and preferences. Preferences may not make sense for Mozilla's implementation - if so, don't use them, or autowire into WebStorage.

> Essentially, I'd like to make both spec independently implementable, even if we chose to extend some objects defined in the widget spec.

> 
>>> 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?

The spec defines the set of widget metadata. If you only choose to use a subset in implementation, thats fine. 

Also, don't worry about the XML - I think the main point of comparison is the Widget Interface spec which already maps a subset of the XML manifest properties to JS properties that make sense in the browsing context of a running widget. 

So manifest properties that only really apply to a packaged widget wouldn't necessarily be used in a JSON representation for a hosted widget.

> 
>>> 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.
> 
>>> 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.

The id property is optional in widgets anyway.

> 
>>> 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'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)?
> 
> 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.

A simple example is a registry or repository for discovering apps without necessarily supporting installation. 

> 
>> 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. 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.

Don't get hung up on the XML bit:

http://www.w3.org/TR/widgets-apis/

(And there isn't an XML schema AFAIK)

> 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?

> 
> 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.

I think you're overestimating the differences between widgets as it stands and Mozilla's implementation and proposal; a converged solution is possible with a little bit of compromise.

> 
> Regards,
> -Anant
> 
>

Received on Monday, 14 May 2012 22:04:24 UTC