Re: [Widgets] Mozilla open apps
On Jun 28, 2011, at 20:17 , Scott Wilson 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. Thanks for picking this up, I think it is indeed a good idea. > On 20 Oct 2010, at 19:40, Mike Hanson wrote: >> 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". I certainly think that content could be augmented to point to a URI (and the configuration would then be sent on its own). I think that this matches some ideas discussed previously in which a widget could be endowed with an HTTP origin in order to function as if it had been acquired from that source. This could be achieved for instance by actually acquiring it from said source (and keeping track of that fact) or by using a signature properly tying the two together. With that approach, the configuration document becomes just a way of describing an app, irrespective of whether it's on the web or on a USB key. AppCache is just a way of controlling the caching of content on the Web, so that the two are complementary. Then there's packaging: it would be really nice if it could be used for more than widgets, notably to package a set of resources (CSS, images, scripts, etc.) that can then be acquired with a single request, what's more compressed. This would not just help performance, it would also help with dependency management when you're fanning your content out to multiple servers and as the content is being deployed you hit stupid issues with v2447 of the CSS being loaded alongside v2448 of the script, which then causes hard to track user bugs (and gets even more amusing with caching involved). This then leaves widgets as nothing more than a convention to have the configuration document at a specific location inside a package (oh, and some silly rules about content localisation). >> 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. Have you looked at how this could integrate with PaySwarm for instance? >> 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? You're correct, this isn't part of the widgets family of specs. But it's something that could be considered. There currently only is access to information about the widget itself, not about the runtime in which it is executing. >> 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? The widget configuration hardly rates as "complex". That being said, it should be rather straightforward to produce a JSON alternative (and both could be accepted, with one taking precedence if both exist). My primary concern would be localisation. While I'm not particularly fond of the content localisation mechanism available in widgets, the configuration localisation is actually quite usable (and, I think, useful). I can think of ways of representing that in JSON, but they aren't particularly nice. At all. >> Localization Model >> The xml:lang based approach is structural analogous (though somewhat tedious >> to handle in JSON, but that's not really important). In t
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 > wrote: >> On Tue, 28 Jun 2011 20:17:38 +0200, Scott Wilson >> 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 > P&C, 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 Wed, Jun 29, 2011 at 12:08 PM, Charles McCathieNevile wrote: > On Tue, 28 Jun 2011 20:17:38 +0200, Scott Wilson > 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 P&C, 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
On Tue, 28 Jun 2011 20:17:38 +0200, Scott Wilson
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 element it would behave rather like a MOWA manifest.
E.g., if there is no 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
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
element it would behave rather like a MOWA manifest. E.g., if there is no
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 s, 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 no
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
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
Re: [Widgets] Mozilla open apps
Hi Mike, On Wed, Oct 20, 2010 at 8:40 PM, 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. > 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
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
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 P&C, 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
On Wed, Oct 20, 2010 at 2:41 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 P&C, 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 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 P&C, 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 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 P&C, 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)
