Re: App Manifest & API Proposal

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?

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

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

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

Regards,
-Anant

Received on Monday, 14 May 2012 17:13:05 UTC