Re: Comparison between Mozilla & Chrome App Manifests

On 22 Dec 2011, at 12:57, Michiel de Jong wrote:

> Hi Ben,
> 
> On Thu, Dec 22, 2011 at 7:34 PM, Ben Francis <ben@tola.me.uk> wrote:
> In comparing the manifest formats for Mozilla Open Web Apps and Chrome hosted apps I hope to converge on a common standard for *hosted* web apps, I have less interest in packaged apps.
> 
> That's fair enough, and it's very admirable what you're doing. I myself am interested in both hosted and unhosted (as i call them) apps

Likewise, Apache Wookie does a bit of both - it uses Widgets as installable packages which it then hosts as embeddable widgets on web platforms such as portals, CMSs etc. So Wookie uses W3C Widgets for installing widgets, but could also happily offer a JSON-based API for widgets it hosts that could be compatible with Mozilla, CRX etc. If anyone fancies submitting a patch, we'd be happy to include it :-)

> , and after reading http://www.brucelawson.co.uk/2011/installable-web-apps-and-interoperability/ (including the comments) i think we need converters like https://github.com/scottbw/crx2widget for going back and forth between all three spec branches (mozilla, google, w3c). Such a set of converters, as open source reusable tools, would have a lot of the benefits that real convergence would have, and might be a good start towards achieving actual convergence. Just like jQuery is a good way to hide differences in DOM implementations, and allows us in practice to "pretend" that these differences don't exist.
> 
> To start with, is there a converter to go from mozilla format to google format and back? Should we make one?

Another complementary tactic is to get as much semantic agreement across the specs, both for packaged and hosted apps. I think this happened to some extent with Mozilla making some of the basic metadata terms the same as W3C; I think this can be taken a bit further. In which case there will be less information lost on conversion. I don't think the semantics of things like "name" and "icon" are a USP for any of these services.

S