Re: [runtime] Application Lifecycle and Events - F2F feedback incorporated

On Oct 2, 2013, at 3:59 PM, Jungkee Song <jungkee.song@samsung.com> wrote:

[...]

Jungkee - thanks for your comments.

>> However, if a ServiceWorker could be bootstrapped off of a manifest, that
>> would not be the case. Feasibility and implications of this should be
>> explored.
>> 
> 
> Although I cannot measure the complexity of the integration (bootstrap a
> ServiceWorker from a manifest) as of now, I presume the expected shape would
> be a very tightly coupled model requiring huge changes in ServiceWorkers,
> which seems not quite a feasible approach.

Given that ServiceWorker is still an early work in progress proposal that does not ship, I'd guess we do not need to be too concerned about making changes or adding things while we brainstorm as long as there's a use case behind that makes sense.

> That said, I'd rather try to
> think of a loosely-coupled model in that a web app bootstraps a *default
> document environment* (index page) in its manifest and the script in the
> page installs ServiceWorkers based on its need. This default document plays
> its role as the single entry point of the app context creating other
> browsing contexts and dispatching persistent events, etc. Also, we can think
> of a way to make(allow) this default page invisible to support background
> service use cases.

Doesn't that sound like an unnecessarily complex model from a web developer's point of view?

I think it may be helpful to try keep implementation details out of the discussion this early in the process, and think how to best address the use cases from a web developer's point of view first.

>>> In my
>>> perspective, background service with no UI must be scoped in SysApps
>>> execution model having use cases such as notification (email,
>>> persistent system event, etc.), data sync, scheduled event, etc.
>> 
>> I assume you mean APIs for persistent system events, scheduled events etc.
>> must be exposed to ServiceWorker scripts?
>> 
>> These features fall within the scope of SysApps, and may or may not be
>> good fit for the open Web, at least not yet. Thus for SysApps purposes
>> there may be a need to extend ServiceWorker.
>> 
> 
> As suggested above, having a default document environment (as a single entry
> point) separate from a ServiceWorker environment would make the integration
> complexity much lower and also allows ServiceWorker be used in a Webby way
> as-is whenever more desirable.

By "need to extend" I did not mean its own environment.

I'd guess web developers might prefer to handle all the events from within the same environment, something like the following for an imaginary foobar event:

oninstall = function () {
  // indicate this ServiceWorker can handle fetch and foobar events
  e.services = ['fetch', 'foobar'];
};

onfetch = function (e) {
  console.log('Fetching ' + e.request.url);
};

onfoobar = function (e) {
  // ...
};

That would mean less boilerplate (e.g. no need for two separate .js files) and potentially less bi-directional discussion between the contexts.

>>> - Lifecycle events
>>> In my understanding, ServiceWokers may be killed by UA at any time
>>> but that does not terminate the entire app, i.e. the documents
>>> registered the worker. In case we happen to work on top of
>>> ServiceWorkers, the definition of the app should be shared between the
>>> two parties. (I presume it's not a trivial topic as the current
>>> ServiceWorkers allow combination of the multiple ServiceWorkers for
>>> multiple scopes.)
>> 
>> As Kenneth mentioned, this is similar to the Event Page model, which seems
>> to behave reasonably in the real world. In your example, the
>> implementation would do its best to try keep the associated
>> ServiceWorker(s) alive if there are open windows.
>> 
> 
> I don't know whether vanilla ServiceWorkers can handle application-wise
> lifecycle events such as onlaunch, onterminate, onpause, on resume.

If (a subset of) the above events make sense for the wider Web and address real use cases, then adding them to ServiceWorker proper sounds reasonable to me.

Currently oninstall, onactivate, onfetch, onbeforeevicted, onevicted are in.

> Having a
> separate default document (i.e. event page indeed) for lifecycle events
> seems to be more flexible, and it seems ServiceWorker has its own unique use
> cases: mainly resource request management (fetch and app cache) which are
> orthogonal.

I can think of use cases that involve fetching resources and populating caches in response to lifecycle events. For example, if an application is resumed, it may want to (re)populate its caches.

If we'd keep these separate, there's a need for some extra bi-directional discussion via the usual postMessage() + onmessage. Perhaps not a big issue, but some extra effort would be needed by the web developer.

>>> - Reason for launch event
>>> ServiceWorkers provide oninstall event but it's all after the
>>> document
>>> (UI) has been being loaded. This makes it impossible to adjust the UI
>>> depending on the reasons.

Wouldn't this be true only on the first time a new page is loaded? After the installation of the ServiceWorker, it should be first consulted when imaginary launch event is fired and can act accordingly, adjust the UI etc.

Or that's how this works for fetch currently IIUC. No?

Thanks,

-Anssi

Received on Wednesday, 9 October 2013 11:32:18 UTC