Re: [Web Workers API] Data synchronization

On Fri, Jan 16, 2009 at 5:17 PM, Nikunj Mehta <nikunj.mehta@oracle.com> wrote:
>
> I have reviewed the draft specification dated 1/14 [1]. I am not sure about
> the status of this spec vis-a-vis this WG. Still, and without having
> reviewed any mailing list archives about prior discussion on this draft,
> here are some questions around the scope of this spec:
>
> 1. Are background workers executing outside the current browsing context
> completely out of consideration? As an implementor of sync engines and
> developer of applications that use them, Oracle's experience shows that
> trickle sync is the most usable approach and that in trickle sync an
> application doesn't need to be active for data to be moved back and forth.

All workers execute outside the context of a current browsing context.
However the lifetime of a dedicated worker is tied to the lifetime of
a browsing context. However shared workers can persist across
contexts.

Extending the lifetime too far beyond the lifetime of a browsing
context has usability, and possibly security, issues though. As a
browser developer I'm not really comfortable with allowing a site to
use up too much resources after a user has navigated away from a site.

> 2. Long running scripts pose a problem especially when script containers
> leak memory over time.  Is it giving too much freedom to workers to run as
> long as they wish and use as many network/memory resources as they wish?

By "script containers", do you mean script engines?

If so, long running scripts are no different from scripts that run
short but often as is the alternative in browsing contexts. We can run
garbage collection in the middle of a running script.

> 3. On devices which do not like background processes making continuous use
> of CPU/network resources (such as iPhone and BlackBerry). how can one take
> advantage of native notification services to provide up-to-date information
> at a low enough resource cost?

This is actually a pretty interesting question.

It's really more a property of which APIs we expose to workers, rather
than the worker API itself I'd say. We need someone to define an API
that allows native notification services to be the transport layer,
and then we can expose that API to workers.

What's interesting is that the HTML5 spec actually makes an attempt at
defining such an API. The problem is that it uses an <eventsource>
element to do it, which means that we can't use the API directly
inside workers.

Hixie: Should we consider making <eventsource> a pure JS API so that
it can be reused for workers?

> 4. Why is the spec biased towards those implementors who would like to
> persist synchronization results and application data in the structured/local
> storage only? Why not consider needs of those who would prefer to keep their
> data accessible directly through HTTP/S, even in the disconnected case?

Because such APIs already exist. As soon as there is a spec for
synchronization with a server I see no reason not to expose that to
workers. Indeed, the people coming up with a server sync API could
define that the API is available to workers if they so desire.

Note that the WebSockets API is exposed to workers, which can be used
to implement server synchronization.

/ Jonas

Received on Saturday, 17 January 2009 02:11:22 UTC