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