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...
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
dev-weba...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
