Re: [manifest] Is the Webapp Manifest spec ready for FPWD?

On Fri, Jun 1, 2012 at 12:40 PM, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> On 1 Jun 2012, at 18:18, Adam Barth <w3c@adambarth.com> wrote:
>
> > On Fri, Jun 1, 2012 at 6:43 AM, Marcos Caceres <w3c@marcosc.com> wrote:
> >> On 31 May 2012, at 23:23, Adam Barth <w3c@adambarth.com> wrote:
> >>> Is anyone besides Mozilla interested in implementing this
> specification?
> >>
> >> I think people are just trying to work out what it does and if it
> >> brings value to particular communities.
> >>
> >> Having said that, the only other really big (i.e. in terms of millions
> of users right now) candidate for implementation is Google as this proposal
> is supposed to harmonise the Chrome store approach to installable Web apps
> with Moz's go at entering the same market (and sharing apps across
> stores/browsers).
> >>
> >> Adam, as you are associated with Google, can you find out if Google's
> chrome store team are interested in moving it forward?
> >
> > My understanding is that standardizing the package format isn't very
> > high on the team's priority list.  They're more interested in
> > standardizing the security model and associated APIs, which is why
> > we're interested in forming the SysApps working group.
>
> Sounds good. AFAICT, Moz's proposal doesn't really cover packaging either
> ... Not in the sense of wrapping the app using zip or something. More
> metadata, feature control (potentially relevant to requiring certain
> SysApps API), and lifecycle management.
>
> > As an example, <
> http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html>
> > has a "required_features" field, which makes some implicit assumptions
> > about the security model.  It seems premature to work on a format for
> > declaring this sort of information without having nailed down the
> > security model.
>
> I agree.
>
> > If I were running the show, I'd take up this work in
> > the SysApps working group after we'd made some progress on the
> > security model and at least a handful of APIs.  Then we'll have
> > something concrete to describe in the manifest.
>
> Seems reasonable.
>
> > Having said that (and I can check with the team if you'd like a
> > definitive answer), I doubt they'd oppose folks working on this topic.
> > I just wouldn't expect much feedback from them in the near term.
>
> That would be appreciated. Might save some cycles and help priorities...
>

Hi all.  I just wanted to chime in here agreeing with Adams points.  Our
take is that defining a manifest format (or for that matter a packaging
format) at this stage is the cart before the horse.  Without a defined
security model or runtime execution model, it's mostly meaningless.  If we
do our jobs right on the security model and runtime definitions, the
features of manifest and packaging will become obvious.  If we agree on the
security and runtime models, but somehow failed to agree on common manifest
or packaging, it would be trivial to map one to the other.  The inverse is
not true.

I agree with Adam's proposal that we table the manifest discussion and pick
it up again in SysApps once we've made more progress.

Erik



>
> > Adam
> >
> >
> >>> On Wed, May 30, 2012 at 11:36 AM, Arthur Barstow <
> art.barstow@nokia.com> wrote:
> >>>> Hi All,
> >>>>
> >>>> Besides the thread below that Anant started a few weeks re the Webapp
> >>>> Manifest spec, Marcos also started a few threads on this spec ...
> >>>>
> >>>> What are people's thoughts on whether or not the Quota Management API
> spec
> >>>> is ready for First Public Working Draft (FPWD)?
> >>>>
> >>>> A "rule of thumb" for FPWD is that the ED's scope should cover most
> of the
> >>>> expected functionality although the depth of some functionality may
> be very
> >>>> shallow, and it is OK if the ED has some open bugs/issues.
> >>>>
> >>>> -Thanks, AB
> >>>>
> >>>> On 5/12/12 2:02 PM, ext Anant Narayanan wrote:
> >>>>>
> >>>>> Hi everyone,
> >>>>>
> >>>>> I recently joined the webapps working group and I'd like to introduce
> >>>>> myself! I work at Mozilla and for the past year or so have been
> working on
> >>>>> our Apps initiative [1]. Our goal has been to make it very easy for
> >>>>> developers to build apps using web technologies that can go above
> and beyond
> >>>>> what one might achieve using "native" SDKs on platforms like iOS and
> >>>>> Android. We're also trying to make it really easy for users to find
> and
> >>>>> acquire these apps, and use them on any device they happen to own
> regardless
> >>>>> of platform.
> >>>>>
> >>>>> As part of this work we have devised a simple JSON based manifest
> format
> >>>>> to describe an installable web app, in addition to a few DOM APIs to
> install
> >>>>> and manage these apps. We have a working implementation of the
> entire system
> >>>>> in our latest Nightly builds.
> >>>>>
> >>>>> The manifest and corresponding APIs are described in an early draft
> at:
> >>>>> http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html
> >>>>>
> >>>>> We'd like to propose using that draft as the basis for a FPWD on this
> >>>>> topic. I look forward to your feedback!
> >>>>>
> >>>>>
> >>>>> FAQs
> >>>>> --
> >>>>> There are a few questions I anticipate in advance, which I will try
> to
> >>>>> answer here, but we can definitely go in more depth as necessary on
> the
> >>>>> list:
> >>>>>
> >>>>> 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), and replacing XML with JSON; the
> other
> >>>>> fundamental difference is that the widget spec describes packaged
> apps,
> >>>>> whereas our manifest describes hosted apps.
> >>>>>
> >>>>> 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!). Packaged apps do have their
> own
> >>>>> advantages though, which we acknowledge, and are open to extending
> the spec
> >>>>> to support both types of apps.
> >>>>>
> >>>>>
> >>>>> Q. Why is the DOM API in the same spec as the manifest?
> >>>>>
> >>>>> A. One success condition for us would be standardize the DOM APIs so
> that
> >>>>> users will be able to visit any app marketplace that publishes web
> apps
> >>>>> conforming to the manifest spec in any browser and be able to
> install and
> >>>>> use them.
> >>>>>
> >>>>> We understand there might be other platforms on which a JS API may
> not be
> >>>>> feasible (for eg: A Java API to install and manage these apps is
> equally
> >>>>> important), but that shouldn't preclude us from standardizing the
> DOM API in
> >>>>> browsers. The manifest and the API go hand-in-hand, as we think each
> of them
> >>>>> is dramatically less useful without the other.
> >>>>>
> >>>>>
> >>>>> Q. Why only one app per origin?
> >>>>>
> >>>>> A. We originally placed this restriction for security reasons. In
> Firefox
> >>>>> (and most other browsers), the domain name is the primary security
> boundary
> >>>>> - cookie jars, localStorage, XHRs are all bound to the domain. For
> >>>>> supporting multiple apps per domain we would have to do some extra
> work to
> >>>>> ensure that (potentially sensitive) permissions granted to one app
> do not
> >>>>> leak into another app from the same domain. Additionally, this lets
> us use
> >>>>> the origin of the domain as a globally unique identifier. Note that
> >>>>> app1.example.org and app2.example.org are two different origins
> under this
> >>>>> scheme.
> >>>>>
> >>>>> That said, we've received a lot of developer feedback about the
> >>>>> inconvenience of this restriction, and we are actively looking to
> lift it
> >>>>> [3]. We cannot do this without a few other changes around
> permissions and
> >>>>> enforcing specific UA behavior in "app mode" (as opposed to "browser
> mode"),
> >>>>> but is something we can work towards.
> >>>>>
> >>>>>
> >>>>> Q. Apps are just web pages, why bother "installing" them?
> >>>>>
> >>>>> A. This has been previously discussed on the list [4]. There are
> clear
> >>>>> differences in perception between an app and a website for most
> users. Most
> >>>>> web content is expected to be free, but the same content wrapped in
> an app
> >>>>> is something people seem to be willing to pay for. Monetization is
> important
> >>>>> to encourage a thriving web developer community.
> >>>>>
> >>>>> Additionally, treating certain "installed" websites as apps gives us
> a
> >>>>> context separate from loading pages in a browser, which allows us to
> provide
> >>>>> privileged APIs to such trusted apps, APIs we would normally not
> give to
> >>>>> untrusted web content.
> >>>>>
> >>>>>
> >>>>> Thanks for reading!
> >>>>>
> >>>>> Regards,
> >>>>> -Anant
> >>>>>
> >>>>> [1] https://mozilla.org/apps/
> >>>>> [2] https://www.w3.org/TR/widgets/
> >>>>> [3]
> >>>>>
> https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/9482dcd34fa8c1a4
> >>>>> [4]
> >>>>>
> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html
> >>>>>
> >>>>
> >>
>
>