I didn't see any, but we had discussed a couple of possible ways to
get there at an earlier meeting.
The first was to perhaps use AppCache manifests to declare this sort
of metadata. You might have some sort of header in the manifest that
describes the page as "persistently bless-able" (much like Ben's
description), followed by the list of requested permissions. UA's
would fetch the AppCache, detect that it corresponds to a blessable
app and handle the process of granting privs enumerated in the
manifest. It'd be up to the UA to find some way to offer the ability
to bless the app/page in it's UI, but in the case of Chromium you
could imagine this all getting integrated into a process by which you
bless an app and it asks for perms like:
* app-mode desktop shortcut
* location
* persistent storage that's not subject to cache clearing
Another way to skin the cat might be to lean on the extensions system
in Chromium to build an extension automatically or for a page to
reference an extension to offer. Installing the extensions might then
be the way things get blessed, but that sort of seems like a question
of semantics and implementation. The first way seems somewhat easier
to eventually standardize and could possibly be implemented as the
second under the covers.
Regards
On Tue, Oct 20, 2009 at 5:36 PM, Nick Baum <nickb...@chromium.org> wrote:
> Open web leads, was there any further discussion of this?
> -Nick
>
> On Sun, Oct 4, 2009 at 8:33 PM, Alex <faab...@mozilla.com> wrote:
>>
>> > That seems like a good plan. Has anyone ever tried formalizing it and
>> > floating it around to other vendors?
>>
>> I figured I should jump into the thread since I can give some
>> perspective on the UI from another vendor. I'm a principal designer
>> on Firefox, and this is a feature that I'm really passionate about.
>>
>> > > The UA would expose some way to activate all of this functionality for
>> > > a site in "one shot"... e.g. if the site published the data via some
>> > > kind of <link> tag then a menu item in the browser might activate that
>> > > the user could use to activate it.
>>
>> I completely agree with the user being able to give the Web app
>> various privileges in "one shot," as opposed to having to provide
>> permissions individually, like access to a certain amount of offline
>> storage, local file type registration, ability to produce
>> notifications, etc (although we will likely allow users to revoke
>> permissions to Web apps individually).
>>
>> I'm concerned that the notion of "installing a Web app" is going to be
>> difficult for a lot of people to wrap their head around. This
>> somewhat implies that the Web app is going to served locally (like how
>> Zimbra Desktop currently deploys with Mozilla's Prism). So in terms
>> of the Firefox UI, we haven't decided on the best way to describe the
>> action of giving a Web app additional desktop-like privileges. While
>> we will likely have an explicit menu item, we are also considering
>> granting these privileges implicitly when the user takes an action
>> like dragging a tab into their OS X Dock, or Windows quick launch
>> bar. We also may grant the Web app certain privileges in Firefox 4
>> when it is dragged to the left of the "home tab," and now exists in a
>> persistent state that we are referring to as an "app tab."
>>
>> I've also been considering the value of adding an additional item to
>> the Windows Start Menu and OS X Applications folder called "Add Web
>> Application," which would generate appropriate shortcuts, and grant
>> the Web app additional privileges. I think conceptually this works
>> well since the interface is placed alongside other desktop apps,
>> however this is a bit more aggressive than Firefox usually behaves.
>>
>> While UA defined semantics and behaviors are of course outside of the
>> standardization process of the API, I think the Web as a whole would
>> benefit if we coordinated to deploy a reasonably similar interface for
>> this functionality.
>>
>> -Alex Faaborg
>>
>>
>> On Oct 2, 4:23 pm, Jeremy Orlow <jor...@chromium.org> wrote:
>> > That seems like a good plan. Has anyone ever tried formalizing it and
>> > floating it around to other vendors?
>> >
>> > On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google)
>> > <b...@chromium.org>wrote:
>> >
>> > > This relates somewhat to how we'd like people to "install" web
>> > > applications.
>> >
>> > > For that we figured a site would publish a manifest in some format
>> > > (there was some talk about something like the extensions manifest)
>> > > that specifies all kinds of appy things a site can do, like large
>> > > icons, protocol schemes and mime types it can handle and the URLs for
>> > > each, etc etc.
>> >
>> > > The UA would expose some way to activate all of this functionality for
>> > > a site in "one shot"... e.g. if the site published the data via some
>> > > kind of <link> tag then a menu item in the browser might activate that
>> > > the user could use to activate it.
>> >
>> > > -Ben
>> >
>> > > On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow <jor...@chromium.org>
>> > > wrote:
>> > > > On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting <pkast...@google.com>
>> > > wrote:
>> >
>> > > >> On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow <jor...@chromium.org>
>> > > wrote:
>> >
>> > > >>> Is this API even part of any standard? Maybe we should bring this
>> > > >>> up
>> > > on
>> > > >>> WhatWG?
>> >
>> > > >> The thread title is a clue that these are specced in HTML5 :)
>> >
>> > > > Not really. People abuse the term HTML5. Good example: WebSockets,
>> > > > WebDatabase, LocalStorage, Workers, and many of the other APIs we
>> > > associate
>> > > > with HTML5 are not in that spec.
>> > > > Anyhow, apparently this was discussed very recently and I somehow
>> > > > missed
>> > > the
>> > > > discussion:
>> >
>> > > >http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/02...
>> > > > I'll try to take a look at the thread some time soon. Ben and/or
>> > > > other
>> > > UI
>> > > > guys, maybe you should too. Now is the time to make noise if we
>> > > > think
>> > > this
>> > > > is a bad API.
>> > > > J
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
