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
