Re: [Widgets] Mozilla open apps
On 29 Jun 2011, at 12:34, Marcos Caceres wrote: On Wed, Jun 29, 2011 at 12:08 PM, Charles McCathieNevile cha...@opera.com wrote: On Tue, 28 Jun 2011 20:17:38 +0200, Scott Wilson scott.bradley.wil...@gmail.com wrote: I think Bruce Lawson was dropping a big hint the other day to look again at the questions Mike posed a long while ago! I know there was discussion at the time, but I think both initiatives have moved on somewhat so its worth returning to. I agree that it is worth returning to. The TPAC meeting in Santa Clara might be a good chance to sit down in the same place and talk about it as well as email, which is generally a better way to clarify what the issues are but not always the most effective way to solve the hard ones. Are people likely to be in the Bay Area in the first week of November, and prepared to spend a bit of time discussing this? I think it is a great idea. However, there is a lot we can do in the *6 months* in between! :) These specs should be at REC by November. As the Last Call period for PC, Dig Sig, and API finished yesterday, Artb will send out a mail today to begin the PR preparation process for most of the Widget specs: WARP and View Modes have met their CR exit criteria, and are also ready to be moved to PR and REC. This means that by September, these specs will be in PR. And REC in November. If we are going to do anything about widgets, it needs to happen sooner rather than later. Mike may want to correct me here, but I couldn't see anything in MOWA that would require changes to the Widgets specifications that are currently on track. I think we can get there via a Note on applying Widget specs in the case of Web Apps (packaged and non-packaged), or further spec work (perhaps under the FSW banner) to cover things like web app store interoperability and trust. -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] Mozilla open apps
On Tue, 28 Jun 2011 20:17:38 +0200, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
I think Bruce Lawson was dropping a big hint the other day to look again
at the questions Mike posed a long while ago! I know there was
discussion at the time, but I think both initiatives have moved on
somewhat so its worth returning to.
I agree that it is worth returning to.
The TPAC meeting in Santa Clara might be a good chance to sit down in the
same place and talk about it as well as email, which is generally a better
way to clarify what the issues are but not always the most effective way
to solve the hard ones.
Are people likely to be in the Bay Area in the first week of November, and
prepared to spend a bit of time discussing this?
cheers
Chaals
On 20 Oct 2010, at 19:40, Mike Hanson wrote:
Note replying here to an old post for context
Hi there -
I can speak for the technical aspects of the Apps project and relay
feedback as needed.
We had looked at the Widget Packaging spec earlier in the project and
had steered away from it because we were focused on the
in-browser/live URL use case. But as we added icons, names,
descriptions, and whatnot, we've converged back on something close to
Widget Packaging.
So... I think, as you note, it's worth making the effort -- I propose
that we try to figure out how to make the Widget spec fit our current
use case, and, if it doesn't, see if we can find a small number of
deltas that get us there.
I'll try to summarize the differences here:
In-Browser/live content usage
Our goal is to encompass in-browser application usage, where some
subset of normal web browsing activity is identified as an app.
This means that we need to identify some subset of the URL value space
that belongs to an app. Our current approach (which is close to the
one proposed by Google [1]) is to identify a URL set (Google allows
regexes; we propose domain-matching with a path prefix). Google
proposes allowing a carve-out of browsable URLs, which can be visited
without leaving the app, presumably for federated login.
Specifically, this means that the content element would need to be
replaced or augmented with some sort of app_urls or somesuch. It also
seems like the HTML5 App Cache proposal is addressing the same problem
space as content; is there some way to harmonize all of this? If we
get this right we can perhaps get a smooth continuum from live web
site to dedicated brower instance to widget.
We also intend to experiment with embedding URLs for service endpoints
-- for example, a cross-document postMessage sink. I don't see an
element that we could adopt for that purpose yet; perhaps we could
propose an extension.
Looking at Mozilla Open Web Application (MOWA) and Widgets today, I
don't see a big issue here. If you host a Widget manifest with or
without a content element it would behave rather like a MOWA manifest.
E.g., if there is no content src=blah or no {launch_path: blah} you
would use the default. In the case of MOWA this is the origin of the
manifest, in the case of Widgets it would be /index.html (etc).
I guess there isn't any guidance on naked Widget manifests as such,
but I've always assumed this would be possible/supported. If we write a
Note on web apps we could put it there.
Per-application metadata repository and access API
We propose that the application repository maintain some metadata
that is in addition to, and along side, the manifest. Specifically, an
authorization URL, signature, installation location and date, and
perhaps an update URL.
The gist of our approach (and the part that is really new, I think) is
that JavaScript running in some web context can ask, has the user
installed an app for my domain? And then, further, if the user has
an authorization URL for my domain, load it now.
You could try to use the Widget API for this, but the trust model isn't
exactly right. Our intent is that the user has a trust relationship
with a store or directory, and has a less trusted relationship with the
app; the app does not discover the authorization URL, for example. In
our thinking this implies that there is a app repository object that
has a couple methods; AFAIK there isn't an equivalent object that has
the list of all installed widgets in the spec. Am I missing
something?
This looks quite similar to the REST APIs that Apache Wookie exposes,
though we don't make them available within the Widget context itself. I
think its quite specific to a type of Widget store model rather than the
Widgets/Apps themselves, and it does seem a bit strange to access them
via the running app script context rather than addressing the server
directly. In any case, there is useful functionality in MOWA (e.g. the
install function could download the actual .wgt, rather like the Opera
Widgets site, or be overridden with
Re: [Widgets] Mozilla open apps
On Wed, Jun 29, 2011 at 12:08 PM, Charles McCathieNevile cha...@opera.com wrote: On Tue, 28 Jun 2011 20:17:38 +0200, Scott Wilson scott.bradley.wil...@gmail.com wrote: I think Bruce Lawson was dropping a big hint the other day to look again at the questions Mike posed a long while ago! I know there was discussion at the time, but I think both initiatives have moved on somewhat so its worth returning to. I agree that it is worth returning to. The TPAC meeting in Santa Clara might be a good chance to sit down in the same place and talk about it as well as email, which is generally a better way to clarify what the issues are but not always the most effective way to solve the hard ones. Are people likely to be in the Bay Area in the first week of November, and prepared to spend a bit of time discussing this? I think it is a great idea. However, there is a lot we can do in the *6 months* in between! :) These specs should be at REC by November. As the Last Call period for PC, Dig Sig, and API finished yesterday, Artb will send out a mail today to begin the PR preparation process for most of the Widget specs: WARP and View Modes have met their CR exit criteria, and are also ready to be moved to PR and REC. This means that by September, these specs will be in PR. And REC in November. If we are going to do anything about widgets, it needs to happen sooner rather than later. -- Marcos Caceres http://datadriven.com.au
Re: [Widgets] Mozilla open apps
I think Bruce Lawson was dropping a big hint the other day to look again at the
questions Mike posed a long while ago! I know there was discussion at the time,
but I think both initiatives have moved on somewhat so its worth returning to.
On 20 Oct 2010, at 19:40, Mike Hanson wrote:
Note replying here to an old post for context
Hi there -
I can speak for the technical aspects of the Apps project and relay feedback
as needed.
We had looked at the Widget Packaging spec earlier in the project and had
steered away from it because we were focused on the in-browser/live URL use
case. But as we added icons, names, descriptions, and whatnot, we've
converged back on something close to Widget Packaging.
So... I think, as you note, it's worth making the effort -- I propose that we
try to figure out how to make the Widget spec fit our current use case, and,
if it doesn't, see if we can find a small number of deltas that get us there.
I'll try to summarize the differences here:
In-Browser/live content usage
Our goal is to encompass in-browser application usage, where some subset of
normal web browsing activity is identified as an app.
This means that we need to identify some subset of the URL value space that
belongs to an app. Our current approach (which is close to the one
proposed by Google [1]) is to identify a URL set (Google allows regexes; we
propose domain-matching with a path prefix). Google proposes allowing a
carve-out of browsable URLs, which can be visited without leaving the app,
presumably for federated login.
Specifically, this means that the content element would need to be replaced
or augmented with some sort of app_urls or somesuch. It also seems like the
HTML5 App Cache proposal is addressing the same problem space as content; is
there some way to harmonize all of this? If we get this right we can perhaps
get a smooth continuum from live web site to dedicated brower instance to
widget.
We also intend to experiment with embedding URLs for service endpoints -- for
example, a cross-document postMessage sink. I don't see an element that we
could adopt for that purpose yet; perhaps we could propose an extension.
Looking at Mozilla Open Web Application (MOWA) and Widgets today, I don't see a
big issue here. If you host a Widget manifest with or without a content
element it would behave rather like a MOWA manifest. E.g., if there is no
content src=blah or no {launch_path: blah} you would use the default. In
the case of MOWA this is the origin of the manifest, in the case of Widgets it
would be /index.html (etc).
I guess there isn't any guidance on naked Widget manifests as such, but I've
always assumed this would be possible/supported. If we write a Note on web
apps we could put it there.
Per-application metadata repository and access API
We propose that the application repository maintain some metadata that is
in addition to, and along side, the manifest. Specifically, an authorization
URL, signature, installation location and date, and perhaps an update URL.
The gist of our approach (and the part that is really new, I think) is that
JavaScript running in some web context can ask, has the user installed an
app for my domain? And then, further, if the user has an authorization
URL for my domain, load it now.
You could try to use the Widget API for this, but the trust model isn't
exactly right. Our intent is that the user has a trust relationship with a
store or directory, and has a less trusted relationship with the app; the app
does not discover the authorization URL, for example. In our thinking this
implies that there is a app repository object that has a couple methods;
AFAIK there isn't an equivalent object that has the list of all installed
widgets in the spec. Am I missing something?
This looks quite similar to the REST APIs that Apache Wookie exposes, though we
don't make them available within the Widget context itself. I think its quite
specific to a type of Widget store model rather than the Widgets/Apps
themselves, and it does seem a bit strange to access them via the running app
script context rather than addressing the server directly. In any case, there
is useful functionality in MOWA (e.g. the install function could download the
actual .wgt, rather like the Opera Widgets site, or be overridden with
implementation-specific behaviour) but it doesn't feel like its either within
the scope of Widgets itself nor a blocker for MOWA using Widgets. Indeed, the
MOWA APIs themselves could be exposed as features, or directly injected into
applications regardless if running on a MOWA-capable Widget server.
XML vs. JSON
Cultural nit: many web developers have trouble with complex XML encodings.
It's frustrating, but true. Would the specification of a JSON dialect be
amenable, or is it that a non-starter?
JSON makes it a little bit easier to implement a
Re: [Widgets] Mozilla open apps
On Wed, Oct 20, 2010 at 12:11 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: I've just had a look at this: https://apps.mozillalabs.com/ In some respects this is very much what we are aiming for (apps using HTML+JS+CSS) however it proposes a new proprietary app manifest format for Widgets that is almost identical to PC, plus an auto-update spec (that isn't Widget Updates). So a lot of reinventing the wheel. Does anyone here have any contact with the project? I don't (sadly)
Re: [Widgets] Mozilla open apps
On 10/20/2010 12:11 PM, Scott Wilson wrote: I've just had a look at this: https://apps.mozillalabs.com/ In some respects this is very much what we are aiming for (apps using HTML+JS+CSS) however it proposes a new proprietary app manifest format for Widgets that is almost identical to PC, plus an auto-update spec (that isn't Widget Updates). So a lot of reinventing the wheel. Does anyone here have any contact with the project? Lloyd Hilaiel might know about the project. -Olli S
Re: [Widgets] Mozilla open apps
On Wed, Oct 20, 2010 at 2:41 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: I've just had a look at this: https://apps.mozillalabs.com/ In some respects this is very much what we are aiming for (apps using HTML+JS+CSS) however it proposes a new proprietary app manifest format for Widgets that is almost identical to PC, plus an auto-update spec (that isn't Widget Updates). So a lot of reinventing the wheel. Does anyone here have any contact with the project? guess contacting #labs @ irc.mozilla.org might be helpful. regards Vivek -- The hidden harmony is better than the obvious!!
Re: [Widgets] Mozilla open apps
On 10/20/2010 02:11 AM, Scott Wilson wrote: I've just had a look at this: https://apps.mozillalabs.com/ In some respects this is very much what we are aiming for (apps using HTML+JS+CSS) however it proposes a new proprietary app manifest format for Widgets that is almost identical to PC, plus an auto-update spec (that isn't Widget Updates). So a lot of reinventing the wheel. Does anyone here have any contact with the project? S I know Mike Hanson has done some work on this project. I'll direct him to this thread. -Brandon
Re: [Widgets] Mozilla open apps
Hi there - I can speak for the technical aspects of the Apps project and relay feedback as needed. We had looked at the Widget Packaging spec earlier in the project and had steered away from it because we were focused on the in-browser/live URL use case. But as we added icons, names, descriptions, and whatnot, we've converged back on something close to Widget Packaging. So... I think, as you note, it's worth making the effort -- I propose that we try to figure out how to make the Widget spec fit our current use case, and, if it doesn't, see if we can find a small number of deltas that get us there. I'll try to summarize the differences here: In-Browser/live content usage Our goal is to encompass in-browser application usage, where some subset of normal web browsing activity is identified as an app. This means that we need to identify some subset of the URL value space that belongs to an app. Our current approach (which is close to the one proposed by Google [1]) is to identify a URL set (Google allows regexes; we propose domain-matching with a path prefix). Google proposes allowing a carve-out of browsable URLs, which can be visited without leaving the app, presumably for federated login. Specifically, this means that the content element would need to be replaced or augmented with some sort of app_urls or somesuch. It also seems like the HTML5 App Cache proposal is addressing the same problem space as content; is there some way to harmonize all of this? If we get this right we can perhaps get a smooth continuum from live web site to dedicated brower instance to widget. We also intend to experiment with embedding URLs for service endpoints -- for example, a cross-document postMessage sink. I don't see an element that we could adopt for that purpose yet; perhaps we could propose an extension. Per-application metadata repository and access API We propose that the application repository maintain some metadata that is in addition to, and along side, the manifest. Specifically, an authorization URL, signature, installation location and date, and perhaps an update URL. The gist of our approach (and the part that is really new, I think) is that JavaScript running in some web context can ask, has the user installed an app for my domain? And then, further, if the user has an authorization URL for my domain, load it now. You could try to use the Widget API for this, but the trust model isn't exactly right. Our intent is that the user has a trust relationship with a store or directory, and has a less trusted relationship with the app; the app does not discover the authorization URL, for example. In our thinking this implies that there is a app repository object that has a couple methods; AFAIK there isn't an equivalent object that has the list of all installed widgets in the spec. Am I missing something? XML vs. JSON Cultural nit: many web developers have trouble with complex XML encodings. It's frustrating, but true. Would the specification of a JSON dialect be amenable, or is it that a non-starter? Localization Model The xml:lang based approach is structural analogous (though somewhat tedious to handle in JSON, but that's not really important). In the absence of a content element, the folder-based localization strategy could hit some bumps. Perhaps extending lang to a couple more elements would be sufficient - we are trying to fit into existing user-agent localization approaches, which might mean that we need to identify a different set of hostnames or launch URLs as well. We can't mandate a folder-based localization model since we are trying to describe existing web content. Widget features we can adopt I think name, description, author, license, icon, and feature are all straightforward enough. Is the assumption that the value space of feature is going to be the W3C Permissions set [2], or something else? (Prior warning: I apologize if I disappear from the list at short notice in a day or two; I have a new baby coming imminently) [1] http://code.google.com/chrome/apps/docs/developers_guide.html [2] http://www.w3.org/TR/2010/WD-api-perms-20101005/ Best, Mike -- Michael Hanson, Mozilla Labs
Re: [Widgets] Mozilla open apps
Hi Mike, On Wed, Oct 20, 2010 at 8:40 PM, Mike Hanson mhan...@mozilla.com wrote: Hi there - I can speak for the technical aspects of the Apps project and relay feedback as needed. We had looked at the Widget Packaging spec earlier in the project and had steered away from it because we were focused on the in-browser/live URL use case. But as we added icons, names, descriptions, and whatnot, we've converged back on something close to Widget Packaging. So... I think, as you note, it's worth making the effort -- I propose that we try to figure out how to make the Widget spec fit our current use case, and, if it doesn't, see if we can find a small number of deltas that get us there. I'll try to summarize the differences here: In-Browser/live content usage Our goal is to encompass in-browser application usage, where some subset of normal web browsing activity is identified as an app. This means that we need to identify some subset of the URL value space that belongs to an app. Our current approach (which is close to the one proposed by Google [1]) is to identify a URL set (Google allows regexes; we propose domain-matching with a path prefix). Google proposes allowing a carve-out of browsable URLs, which can be visited without leaving the app, presumably for federated login. Specifically, this means that the content element would need to be replaced or augmented with some sort of app_urls or somesuch. It also seems like the HTML5 App Cache proposal is addressing the same problem space as content; is there some way to harmonize all of this? If we get this right we can perhaps get a smooth continuum from live web site to dedicated brower instance to widget. We also intend to experiment with embedding URLs for service endpoints -- for example, a cross-document postMessage sink. I don't see an element that we could adopt for that purpose yet; perhaps we could propose an extension. Per-application metadata repository and access API We propose that the application repository maintain some metadata that is in addition to, and along side, the manifest. Specifically, an authorization URL, signature, installation location and date, and perhaps an update URL. The gist of our approach (and the part that is really new, I think) is that JavaScript running in some web context can ask, has the user installed an app for my domain? And then, further, if the user has an authorization URL for my domain, load it now. You could try to use the Widget API for this, but the trust model isn't exactly right. Our intent is that the user has a trust relationship with a store or directory, and has a less trusted relationship with the app; the app does not discover the authorization URL, for example. In our thinking this implies that there is a app repository object that has a couple methods; AFAIK there isn't an equivalent object that has the list of all installed widgets in the spec. Am I missing something? XML vs. JSON Cultural nit: many web developers have trouble with complex XML encodings. It's frustrating, but true. Would the specification of a JSON dialect be amenable, or is it that a non-starter? Certainly not. We could happily have both: If widget contains JSON manifest, use that. Otherwise, use the XML one. Hopefully, we can just layer the JSON on top without breaking backwards compat. I'm happy to discuss this further. Localization Model The xml:lang based approach is structural analogous (though somewhat tedious to handle in JSON, but that's not really important). In the absence of a content element, the folder-based localization strategy could hit some bumps. Perhaps extending lang to a couple more elements would be sufficient Sounds ok to me. - we are trying to fit into existing user-agent localization approaches, which might mean that we need to identify a different set of hostnames or launch URLs as well. We can't mandate a folder-based localization model since we are trying to describe existing web content. Widget features we can adopt I think name, description, author, license, icon, and feature are all straightforward enough. Is the assumption that the value space of feature is going to be the W3C Permissions set [2], or something else? (Prior warning: I apologize if I disappear from the list at short notice in a day or two; I have a new baby coming imminently) Congrats! :) [1] http://code.google.com/chrome/apps/docs/developers_guide.html [2] http://www.w3.org/TR/2010/WD-api-perms-20101005/ Best, Mike -- Michael Hanson, Mozilla Labs -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Re: [Widgets] Mozilla open apps
On 20 Oct 2010, at 19:40, Mike Hanson wrote: Hi there - I can speak for the technical aspects of the Apps project and relay feedback as needed. We had looked at the Widget Packaging spec earlier in the project and had steered away from it because we were focused on the in-browser/live URL use case. But as we added icons, names, descriptions, and whatnot, we've converged back on something close to Widget Packaging. So... I think, as you note, it's worth making the effort -- I propose that we try to figure out how to make the Widget spec fit our current use case, and, if it doesn't, see if we can find a small number of deltas that get us there. Great! I'll try to summarize the differences here: In-Browser/live content usage Our goal is to encompass in-browser application usage, where some subset of normal web browsing activity is identified as an app. This means that we need to identify some subset of the URL value space that belongs to an app. Our current approach (which is close to the one proposed by Google [1]) is to identify a URL set (Google allows regexes; we propose domain-matching with a path prefix). Google proposes allowing a carve-out of browsable URLs, which can be visited without leaving the app, presumably for federated login. Specifically, this means that the content element would need to be replaced or augmented with some sort of app_urls or somesuch. It also seems like the HTML5 App Cache proposal is addressing the same problem space as content; is there some way to harmonize all of this? If we get this right we can perhaps get a smooth continuum from live web site to dedicated brower instance to widget. We also intend to experiment with embedding URLs for service endpoints -- for example, a cross-document postMessage sink. I don't see an element that we could adopt for that purpose yet; perhaps we could propose an extension. In Apache Wookie we have several proposals for inter-widget communications (IWC). A good summary of existing approaches has been developed by Ivan Zuzak [1] and we are taking these forward through community contributions. In general we have found IWC to be sufficiently orthogonal to the core Widget packaging and APIs to be implemented using the existing Feature extension mechanism rather than needing anything special in the spec. Per-application metadata repository and access API We propose that the application repository maintain some metadata that is in addition to, and along side, the manifest. Specifically, an authorization URL, signature, installation location and date, and perhaps an update URL. Update URLs are described in Widget Updates [2] - worth taking a look at. Signatures are described in Widgets: Digital Signatures [3] - also worth a look. I agree that app store metadata is also a useful thing to look at. Some time ago there was a discussion on this list of proposing some additions to the Atom Syndication Format for sharing app store listings, and it may be useful to revisit that. The gist of our approach (and the part that is really new, I think) is that JavaScript running in some web context can ask, has the user installed an app for my domain? And then, further, if the user has an authorization URL for my domain, load it now. You could try to use the Widget API for this, but the trust model isn't exactly right. Our intent is that the user has a trust relationship with a store or directory, and has a less trusted relationship with the app; the app does not discover the authorization URL, for example. In our thinking this implies that there is a app repository object that has a couple methods; AFAIK there isn't an equivalent object that has the list of all installed widgets in the spec. Am I missing something? Apache Wookie also uses Widgets in the in-browser case. We just add our own parameters to the URL to identify the Widget Instance as opposed to the canonical widget URI. In our case, the specific Wookie install (the app store, whether generally open or enterprise-specific) is assumed to be trusted by the container (e.g. Wordpress, JetSpeed etc). It is also responsible for providing the list of installed widgets to the container via a REST API [4] - is that the same sort of thing? XML vs. JSON Cultural nit: many web developers have trouble with complex XML encodings. It's frustrating, but true. Would the specification of a JSON dialect be amenable, or is it that a non-starter? I can't see that being much of an issue. Though TBH the processing of the semantics of the package is more challenging than the syntax. Localization Model The xml:lang based approach is structural analogous (though somewhat tedious to handle in JSON, but that's not really important). In the absence of a content element, the folder-based localization strategy could hit some bumps. Perhaps extending lang to a couple more
Re: [Widgets] Mozilla open apps
Hi, Mike- The Mozilla Open Apps project looks cool, and I hope it can work out to be compatible with Widgets. Your extensions and use cases seem useful. This would be a good thing for everyone involved. Mike Hanson wrote (on 10/20/10 2:40 PM): *In-Browser/live content usage* Our goal is to encompass in-browser application usage, where some subset of normal web browsing activity is identified as an app. It seems that that might be a reasonable use case for the new Widgets Embedding spec [1]: [[ Widgets Embedding: a mechanism to allow embedding of packaged applications within other Web content, such as referencing via the HTML object element. This is a new deliverable for the WebApps WG. ]] (Prior warning: I apologize if I disappear from the list at short notice in a day or two; I have a new baby coming imminently) Congratulations to you and your family! [1] http://www.w3.org/2010/webapps/charter/Overview.html#widget-embedding Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
