Spec name

[kenchris]

In response to w3ctag/design-reviews#279

I find it a bit confusing that it is called background fetch.

First of all, I am afraid that people who look to do long running uploads won't find the feature due to the name. But I also find the background term a bit confusing, especially because to most developers, the Service Worker already runs in the background, so now we have something running in the background of the background.

What I really believe this is, is a transfer manager for async transfers that can outlive service worker lives. It is more about long running than it is about background. I would probably go with something like Long running transfers.

With that in mind, we could also rename backgroundfetch* and backgroundFetch to transfer, and we avoid the double fetch in await registration.backgroundFetch.fetch(id, requests, options); which would become await registration.transfer.fetch(id, requests, options);. transferManager might be another suggestion.

Event names would also be shorter, eg. backgroundfetchcomplete vs transfercomplete

[jakearchibald]

to most developers, the Service Worker already runs in the background, so now we have something running in the background of the background.

A background fetch isn't necessarily launched from a service worker, so the wrapping you imply doesn't really make sense.

What I really believe this is, is a transfer manager for async transfers that can outlive service worker lives. It is more about long running than it is about background. I would probably go with something like Long running transfers.

If we're going to play semantics, then "transfer" doesn't make sense, as that suggests that the thing is no longer accessible at its source. If you're unconvinced, please transfer me £5000.

Not only that, but we already have transferrables in the platform, transferring means you lose access to the thing in the source, and they're closely associated with workers.

Long running

A background fetch won't fail if (due to excellent network conditions) it is "short running".

Avoiding "fetch" for something that is, by definition, a fetch, seems weird. Do you think fetch() should be renamed too? Didn't we already go through this in #80?

With that in mind, we could also rename backgroundfetch* and backgroundFetch to transfer

You've defined "transfer" to mean the same as "fetch", now you're proposing that we use it as an event name on the same object where we already have fetch.

we avoid the double fetch in await registration.backgroundFetch.fetch(id, requests, options);

But only because you've picked two words that mean the same thing in this context.

Event names would also be shorter, eg. backgroundfetchcomplete vs transfercomplete

Only because you've omitted "background", and haven't replaced it with anything that communicates anything similar.

[kenchris]

Good point about transfer, and about it not necessarily being launched from the SW.

Yes, I am not a big fan of the name fetch, but it is too late to change.

I am not a big fan of the word background in general. Any async fetch basically runs in the background, depending on definition. This seems to be more because it is running out-of-line, and you don't necessarily have a reference to the object. I was trying to come up with a more descriptive word, but I see that transfer has similar problems

[jakearchibald]

I don't think we should deviate from "fetch" for the same reasons I gave in #80.

As for "background", I get that it's an overloaded term, but I haven't heard or thought of anything better. Also, other systems use "background" in a similar way.

[kenchris]

The examples in the explainer are (all?) showing service worker integration. I think it makes sense to show examples of it being used outside of service worker. From first glance over the spec, I didn't notice it was exposed to Window as well, though that makes a lot of sense.

[kenchris]

So background fetches are potential long running tasks. Have you thought about whether we will get support for other similar long running tasks in the future?

Potentially there is the use-case for geolocation (cc @anssik) and sensors (cc @dontcallmedom @anssik).

Would it make sense to make BackgroundFetchManager more generic, and accessible via background instead?

--
Apple seem to support the following things in background on iOS (from your link): audio, (geo)location, voip, bluetooth, fetch and notification.

[jakearchibald]

The examples in the explainer are (all?) showing service worker integration. I think it makes sense to show examples of it being used outside of service worker.

Two of the four examples in the explainer show the background fetch being initiated from a page.

Would it make sense to make BackgroundFetchManager more generic, and accessible via background instead?

I don't see the benefit.

[kenchris]

Yes, the only way to get the BackgroundFetchManager seems to be via the service worker registration. Is there any reason why it is not just exposed on Navigator as well?

[jakearchibald]

Is there any reason why it is not just exposed on Navigator as well?

Where would you fire the "complete" or "fail" event?

[kenchris]

I don't see the benefit.

I guess this depends on how we end up exposing Geolocation (geofencing), Sensors (step counter) etc. If we want things to run when the browser/service worker isn't, then using a worker is not enough, and we might end up with objects like BackgroundGeolocationManager etc as well, but maybe that is acceptable.

[anssiko]

@kenchris, could you open an issue at https://github.com/WICG/geolocation-sensor (for Geolocation specifics) and/or at https://github.com/w3c/sensors/ (if a generic feature) and link back to this issue. Thanks!

This is to bring this discussion to the Devices and Sensors group's attention responsible for those specs.

[jakearchibald]

and we might end up with objects like BackgroundGeolocationManager etc as well, but maybe that is acceptable.

I think that's ok. Otherwise, if we go for reg.background.fetch, but the shape of it means that background geo doesn't really fit, we end up with reg.background.fetch and reg.backgroundGeo, which seems worse.

[jakearchibald]

This issue kinda sprawled. If any is it is still relevant, open specific issues.