On 7/9/2013 5:38 PM, Brett Zamir wrote:
Hi,
Encouraging to see this discussion as my dissatisfaction with the
hassle of packaged apps led me to my however humble work on
https://github.com/brettz9/asyouwish/ . Replies below...
I should clarify here that I mean dissatisfaction with packaged apps in
the generic sense of browser extensions as well as packaged mobile web
apps. (I have not yet made a FF OS version of AsYouWish.)
Brett
On 7/9/2013 8:36 AM, Benjamin Smedberg wrote:
On 7/8/2013 5:31 PM, Ben Francis wrote:
What's sad about this vision of the future is that many of the most
interesting apps that get written using web technologies like HTML,
CSS and
JavaScript will not actually be part of the web.
I don't think this is true or sad!
While I agree with some of the motivation behind your arguments
(though see below), I think the situation is indeed sad for a number
of reasons.
I have personally witnessed several examples in my or others'
proposals to WhatWG which were rejected because the WhatWG apparently
felt that HTML beyond the Web was not their business or that a server
environment can be taken for granted. One example was the rejection
(at least at the time) of client-side includes, another was for a
mechanism of client-side entities, and another was the cold
reassurance that the adding of new globals like "Worker" (instead of
scoping new APIs into some namespace, as has been done in some cases
by adding to say the "navigator" global) was safe because Google's
search engine was used to check whether a variable had been used
frequently or not.
There indeed appears to be even an open admission of failing to take
into account all environments of usage, though I would agree that that
itself does not necessitate moving away from non-web usages (and I
would hope the dismissive "online-only" attitude would change).
However, I think there are other compelling reasons for privileged
online apps (if I can extend "online" to also include the "file://"
protocol along with http/s), with the most important being the ease of
publishing and consumption of such apps.
One of the fundamental strengths of the web is that you can download
an entire "page" and save it locally, and even view-source and hack it.
With the advent of online web apps, it has become much more difficult
to view-source the web, because dynamic loading and complex
multi-page apps often don't give you a way to download and
view-source the entire app. It also means that there is often not
clear separate between the client logic in the app and the server
logic that most apps depend on.
First of all, there are tools to view the generated source or
potentially view generated code so at least client-side code can be
introspected (and generally without going through other additional
hoops as with packaged apps).
Yes, preventing online distribution of apps in favor of packaged ones
may COMPEL ALL people to distribute their code in entirety (or more
likely, go to non-web solutions), but why force this? It is one thing
to want applications written in HTML or JavaScript so that one can
introspect the code that is run in one's own machine in a familiar
language (though I'm not so sure force is the best solution even
there). But if you want to see server-side-dependent code become less
opaque, why not go with the following less universally compelling and
cumbersome solutions?
1) Evangelize licenses like the AGPL if you want to promote apps
including their server-side code.
Few developers choose this license from what I can tell, however, as
we ourselves don't want to be compelled so stringently--though if you
do send us code, many will indeed bristle against our own machines
being used as black boxes (as with non-standard plug-in code).
2) Bake more server-interactive functionality into client-side
languages like HTML/JavaScript in a transparent manner so that one
would, for such apps, be clear on what is (most likely) happening on
the server without needing to introspect its code even while leaving
apps free to interact with the server.***
Packaged apps are the most elegant "stupidly simple" solution to the
offline problem that continues to plague those who want unpackaged
apps to work as if they were downloadable entities.
But many of us--as users or developers--don't want apps to work as
downloadable entities! It is a hassle to package apps, it slows
development time, it is annoying to users--including to users who wish
to inspect them (e.g., all the darn XPI and JAR files I have to unzip
to introspect some Firefox extensions). Moreover, packaging, if it
needs to exist at all, should be an implementation detail--if your
browser really feels the need to save space, go ahead and do the
packaging for me, but don't require me to zip things myself, learn
build scripts, etc.
The web is great in large part because anyone can start working on it
today without going through unnecessary hoops. File packaging is a
hoop--and an annoying one given especially the frequency of use we're
describing here. I want to spend time programming, not zipping or
unzipping files. I can't tell you how much faster I have been able to
develop (despite a number of personal limitations) what I think are
some pretty cool proof-of-concept demos without the hassle of file
packaging by using my AsYouWish add-on which is my interim solution
for such transparent requests of privileges from regular websites (to
the SDK API): https://github.com/brettz9/asyouwish/tree/master/demos
(experimental Firefox addon needed,
https://addons.mozilla.org/en-US/firefox/addon/as-you-wish/ along with
add-on options configured to even accept privileged requests from a
given protocol/site)
Packaged apps are not a problem or something to be "sad" about, but
something to rejoice in. They are a way of empowering users. We
should be encouraging all app authors to use packaged apps, even if
they don't need any special permissions.
If the criterion is to ensure code is self-contained, then one could
achieve this by allowing web authors to send a flag in their code
indicating the program was wholly self-contained (kind of a reverse
appcache---cache everything by default).
But it is hardly inevitable or pleasurable that one should:
1) be forced to take an extra steps of packaging my own app for
distribution, unpackaging someone else's app to introspect or hack on
it, or deal with a build system. I also want the Web to be equally
easy for any newcomers to the Web whose ideas may otherwise remain
undeveloped because of these however seemingly small barriers to entry.
2) be restricted from developing apps which have server interactions
where the interactivity is useful
I would hope that in the search for a non-packaged privileged access
solution, the (potentially cross-browser) proposed privileged API for
mobile and non-mobile, independent apps and extensions (of desktop or
mobile browsers or systems), could be harmonized with each other:
https://bugzilla.mozilla.org/show_bug.cgi?id=848647 and even with the
likes of Node.js: https://bugzilla.mozilla.org/show_bug.cgi?id=855936
Best wishes,
Brett
*** There is a lot of lip service given to building RESTful
applications, but the fact remains that RESTful APIs are not wholly
reusable; different sites use different query parameters for the same
purpose.
If, however, certain headers were used to make make secure but
otherwise arbitrary XPath or CSS Selector queries against a document
(e.g., somewhat along the lines of the Range header, but for
HTML-aware piecemeal delivery of documents instead of byte-wise
access), besides enabling privileged clients to treat the web,
including otherwise static files, more as its own XML database, and
besides allowing one to get genuine reusability across websites of
web-friendly query APIs (and thus better introspectability), HTML
itself could prescribe usage of these headers to tie in markup for
server-side interaction, thereby also minimizing server-side coding
and need for 3rd-party library inclusion (unless so desired by the
server) while ensuring powerful querying functionality is more
available by default on even simple web documents.
For example, for clients advertising support for this header feature,
even a static document could be scanned by a server before being
served to the user, and delivered, e.g., with all tables above say 50
rows to be truncated to the first 50 rows, and with markup added to
indicate to the client (subject to its own user preferences) that _the
table could have pagination controls added browser-side_. This would
provide frequently-used functionality without need for third party
libraries or custom server-side programming.
Similar functionality could be added to allow hierarchical list
drill-downs, paragraph range selections, etc., and although schemas
have fallen out of favor, if also specified (as in a header), a
browser could do even more in partnership with the server, e.g.:
1) type-aware sorting of tables (without the ugliness of what is
apparently emerging out of the current standard with each cell needing
its own type markup)
2) type-aware searches of tables or other elements, e.g., browser
display of date controls for date-type columns (or number ranges for
numeric fields, etc.), allowing users to make queries to obtain all
records whose values lie within a specific date range.
Mechanisms could also be added to allow easy caching/offline storage
of hitherto-retrieved rows.
The above markup-header interaction could encourage introspection by:
1) Facilitating offline application development
2) Avoiding an undue generation of custom coding and thus effort in
deciphering server-side APIs and code
...while continuing to avoid coupling the HTML language to any
database or static file format (and avoiding file packaging).
I've started some initial work on this idea at
https://github.com/brettz9/httpquery though I am currently trying to
simplify the proposed header field syntax and streamline it with
standard practices.
To solve the problems mentioned by TimBL, we should just make sure
that servers can serve up a packaged app at a URL, and clients can
just use it and choose to keep it on their homescreen or not, and
their client would keep using that URL to check for updates.
(Ignoring for the moment the special security requirements with
high-privilege APIs, stores, signing, and all that stuff). Then "app
search" is again the same as "web search".
--BDS
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
