Re: Lifecycle - booting up web apps

Hey Marcos,

Responses are inline.

Kevin Peno
E: kevinpeno@gmail.com
C: 425.408.1094


On Tue, Sep 6, 2011 at 12:18 AM, Marcos Caceres <w3c@marcosc.com> wrote:

> Hi Kevin,
>
>
> On Monday, September 5, 2011 at 6:34 PM, Kevin Peno wrote:
>
> > When we talk about passing arguments via query string, I can't help but
> thing of all the things that go on at the server before the user agent even
> gets to rendering, much less DOMContentLoaded. To me it sounds like we need
> an event that fires before anything is done with the document at all.
> Right, this is why I said in the previous email that I wanted to avoid the
> whole RESTful aspect… it seems we need a general working model of what an
> "Installable Web App" is for sanity:
>
> 1. is it a W3C Widget running on a local machine?
>
> 2. A W3C Widget running on a server, whose content is served in a web page
> (e.g., Wookie, Google gadgets)?
>
> 2. is it an (PHP, Ruby, foo) application on the server that is served and
> whose resources are cached through app cache?
>
> My working assumption is something like 1: a W3C widget or a PhoneGap
> application (i.e., a locally installed native application… written in html,
> css, javascript).
>
> I think we need another thread just to nail this down as a group. There is
> no need to just pick one, we could tackle the issues for all three (or more)
> case.
>

I apologize for looking too deeply into the query string example.

RE: "Installable Web App", this is why I like the processing instruction
approach. This gives a clean interface for what to call (which doesn't have
to be local) and doesn't limit us from supporting all of the above.

>
> > Something similar exists in XML with the xml-stylesheet processing
> instruction. If set to an xsl document then, before the output is displayed,
> the XSL processor takes the data and outputs the resulting document. A
> similar processing instruction could be created to native apps? Here's the
> doc I'd see loaded for a web app prior to bootstrap:
> >
> > <?xml version="1.0"?>
> > <?web-app-bootstrap type="application/javascript" href="./bootstap.js"?>
> > <app>
> > <name>My Cool Web App</name>
> > <version>0.1</version>
> > </app>
>
> This is kinda interesting… and a good analogy.
>
> >
> > The pros to this are that the app could be given a blank DOM by the user
> agent when it loads (perhaps even blank HTML DOM so that things like
> document.body are available) and that, theoretically, everything will be
> "ready" when the bootstrap runs. This lets the app do whatever it wants.
> Some cons: requires XML, not backward compatible. I'm sure there are others.
>
> The cons is that I need to hack bootstrap.js. The use case I wanted to
> focus on was starting an application from the command line (as I assume the
> App is a black box … like a zip file).
>

I'm not sure what you'd have to hack about it. Most languages provide a way
to get command arguments. For example: PHP's $argv, Java/C# main( args[] ).
In all cases it would be up to the application to handle processing those
arguments and user-agent to support that language. Support including how to
pass it start up args (whether they be from query string, etc) and,
possibly, calling start up methods. The PI could be expanded to specify the
argument handling method used by the implementer (ex. method="args" or
method="POST"), or maybe it just becomes part of the markup.

As far as "black box" goes. I don't see how that matters much in regards to
this spec. This would be up to the implementor to handle. For example, PHP
has a jar-like system called phar. When a phar is loaded, you can include
other files from within the phar, but the phar format and processor handles
how to find those files. It also handles mapping the relationships of
whatever I pass into phar upon "compile". I assume jar works very similar,
but I have limited experience with Java. If I'm missing something I
apologize!


>
> > An alternative could be to simply add an attribute to script elements in
> the head of a document to differentiate between script elements in head and
> execute bootstrap first.
> >
> > <script type="application/javascript" src="./bootstrap"
> bootstrap="bootstrap"></script>
> Right, again, the use case is a little different. But absolutely this
> solves the problem for traditional web applications.
> >
> > Pro: by putting this as the first script in the document, it is backward
> compatible to current parser/dom execution of scripts (it will get executed
> first [mostly], before display is available).
> > Cons:
> > The document is not "ready" when this is called. This isn't a terrible
> thing, but it means that the application can only load any dependencies and
> save those config options. Then it would have to set a callback on whatever
> even it wants (DOMContentLoaded for example) to start the application
> "loop".
> >  If we specify that this must be executed first, then parsers will have
> to look ahead to find it and run the script. I don't think browser vendors
> (specifically) will like this since it will slow display in a case where
> bootstrap doesn't exist.
> >
> > Now for more coffee...
> Me too! :)
>
>
>