On 07/09/2013 08:52 AM, Kannan Vijayan wrote:
Lifting the app:// protocol up to https://, leaving everything else the
same, doesn't
seem like it should be that big of a difficulty. This would resolve the
"apps don't have
a URI" issue directly.. if perhaps in a shallow way.
Except that we might not want to penalize the loading time of applications
by doing 2 synchronous requests to the server for each file.
The other issues seem more challenging. The main challenge of packaged vs.
non-packaged apps relates to deficiencies in connectivity in the current
mobile world.
> […]
>
> This model doesn't fit so well with the mobile world, where each access
to the
> network, and each byte transferred, may be ridiculously expensive. Under
> that context,
> it's very important to clearly define the boundaries between actions that
> induce network
> traffic, and actions that stay within resources that have already been
pulled.
>
I agree, and where I think packaged app (zip of all used files) are good for
the size of the initial download (even if they are way smaller than Android
ones) but I do not think this is good for updates. Suppose, I have a web
site with 10 pages. I want to add an extra page. I will probably modify
one existing page and add the new page into the zip file. Why should we
re-download all resources, instead of the 2 modified files?
Packaged apps have the advantages of providing a way to do one network
access to see if a new version is available where app-cache will do one
access for each page, and might even get an inconsistent update. To solve
that we can only check the manifest file for updates, and assume that the
manifest file (if present) ensure that other resources present in the
app-cache are still valid.
Packaged apps are smaller and faster to read, as they are contained in one
monolithic zip file. But I do not see any limitations in Gecko for building
a zip file out-of the app-cache manifest. On the contrary, we can even do
better by sorting the files in function of the order in which they are
listed in other pages or how frequently they are used.
In addition, if we are packing our-self the resources, we can re-pack them
with additional meta-data such as the pre-compiled code for asm.js or the
pre-parse lazy-script & bytecode for non-asm.js code.
--
Nicolas B. Pierron
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
