On 9/16/10 6:10 PM, Nathan wrote:
Marcos Caceres wrote:
On Thu, Sep 16, 2010 at 1:42 PM, Nathan <nat...@webr3.org> wrote:
cc: public-webapps
Hi Claes,
Nilsson, Claes1 wrote:
Hi Nathan,
Thanks for clarifying your proposal.
I interpret you so that you are proposing standardization of a general
concept of "packaged and installed web applications". Something like
http://code.google.com/chrome/apps/docs/index.html plus additional
features
from widgets specifications.
This is something that can have a value by several reasons, for
example:
* Whole application package or only manifest/configuration file
could be
digitally signed.
* Permission to use APIs could be given at installation time.
* Manifest/configuration file could define network access limitations.
* Web application marketing/deployment/charging advantages.
I agree that the specifications you mention are applicable for a
general
concept of "packaged and installed web applications" but I believe that
currently most people have the view that "widgets" are "packaged and
installed web applications" that run small "live" applications on
the home
screen. However, what does the widgets specifications actually say? I
haven't digged into the documents in detail but are they not already
enabling a general concept of "packaged and installed web
applications"?
So far there has been a distinction between "browser", running dynamic
content on web sites and "widget user agent", running installed web
widgets.
Reading you original mail in this thread you say:
" Simply wondering why WARP, Widgets Updates and Digital Signatures
aren't
used to deploy js applications which run in the main browser context?".
So, what are you actually proposing?
* Update to HTML5 to support "packaged and installed web
applications" in
the "main browser context"?
Plus
* Updates to the Widgets specifications to enable the more general
concept
of "packaged and installed web applications"?
I'm proposing something before that, to consider whether "packaged and
installed web applications" should be considered and if it would be
viable +
gain support from the main browser vendors, then to look at exactly
how. I'd
loosely suggest that the work done on the Widgets specifications
could be
re-used, forked or even that the Widgets specifications were
re-scoped to
general client side web applications and aligned with the other work
being
done within web-apps, html5 and device-apis. Ultimately it just
seemed to me
like much of the heavy lifting has already been done under the banner of
widgets.
I thought that is what we had done already? I don't get it.
Furthermore, do we really want "packaged and installed web
applications"
to run by the same user agent, i.e. the normal browser as normal
website
based web applications? We may want to have different "user agent
chromes"
depending on type of web application.
Personally, yes, being able to make applications using a suite of
standardized languages and APIs with near universal deployment on a
core set
of rapidly evolving runtimes, really, really, appeals :) I wouldn't
suggest
that the scope be limited to user agent (ie browser vendors) only,
but they
are the obvious target for most applications in the first instance.
As above. I thought that was what we (Web Apps WG - Widgets) have been
doing for the last 5 years?
Maybe I've missed part of the specifications - are you telling me that I
can package up an HTML,CSS,JS based application as per the widgets
specification, include a WARP, Digital Signature, set the view-mode to
windowed and that this will run as is, in the main browser context of
the main browser vendors (Firefox, Safari, Opera, Chrome, IE etc)?
Ah! ok. I get it now. No, that won't work right now (actually, that's
how we run them in our development environment for testing purposes :)
). But that is trivial and no one has really asked for that.
I'm still a bit lost as to what the use case is?
--
Marcos Caceres
Opera Software
