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
