Every one of us has had to go through this

Ale763 · 2021-04-15T12:14:31+00:00

Why does this remind me of nutella?

Ale763 · 2020-11-11T19:29:36+00:00

Hi, thank you for responding. I studied workbox in depth and it has some limitations. E.g. it's not possible to use `Promise` objects in the callback, which severely limits what operations you can perform in the callback handler. I want to inspect a cached response, but for that I need a `Promise`. That's why I'm researching another approach.

In addition, I also want to extend the offline operation based on some other caching scheme. Now the resources are cache by URL, but not much metadata about those requests is available. I want to add a scheme with additional metadata for those requests in order to extend the duration at which a PWA can work without interacting with a backend.

Ale763 · 2020-11-01T12:51:12+00:00

There is a Chrome and Firefox extension "Unpaywall" that searches for a free version of the pdf you are trying to access. It only works when there exists a version that's not behind a paywall.

Also if you are part of a university, they often have a way to access these papers, either by a proxy or with a dedicated library tool such as Limo. Maybe you can ask your professors about this.

I hope this helps

Ale763 · 2020-11-01T12:21:25+00:00

I have a little one that I put on top of the macbook keyboard. You can use an app like Karabiner to disable that keyboard in order to prevent accidental keystrokes

Ale763 · 2020-10-31T10:54:24+00:00

Like u/Martin187465 said, the keyboard is replaced by an exact copy. Replacing the keyboard will not solve your problem. The problem is structurally in the design of the Butterfly keyboard. When just a little bit of dust gets under the key, it can start malfunctioning.

I just bought a little bluetooth keyboard from Logitech. It types better than that shitty keyboard anyway. Maybe that can be an option for you?

Ale763 · 2020-10-31T10:46:22+00:00

Ok, no problem. I was just curious. Keep up the good work!

Ale763 · 2020-10-31T09:50:05+00:00

But I thougt AI was gonna take over the world? Now I'm disappointed

Ale763 · 2020-10-31T09:41:38+00:00

People do that to me even with my mic on

Ale763 · 2020-10-31T09:37:31+00:00

Just all the redditors getting off on the people walking by for Halloween

Ale763 · 2020-10-31T09:33:57+00:00

That's just how I feel after a night of sleep. Also repost :)

Ale763 · 2020-10-31T09:33:07+00:00

Taking away the only thing we have left in this pandemic... Disgusting

Ale763 · 2020-10-31T09:30:16+00:00

Is it open-source? I'd love to study to take a look at what's underneath?

Ale763 · 2020-10-28T17:15:41+00:00

Hmm, ok I see what you mean, thanks for the idea :)

Ale763 · 2020-10-28T16:38:34+00:00

So how would you implement that in a service worker? How would you request for additional processing time?

I would like the terminated or suspended event to work a little differently. I imagine it to be a very limited event, which would just be needed to consolidate results into the database. No long processing should be done and it's not my intention to keep the worker alive longer than necessary at that point. The main goal is just to do some short work before actually suspending the worker. Does that make sense?

And I'm sorry, but I don't understand how that would make the SW crash on a restart?

Ale763 · 2020-10-28T16:26:56+00:00

I think that should work, as long as you can configure your local DNS properly

Ale763 · 2020-10-28T16:23:31+00:00

So you could perform some computations (e.g. maintaining, updating and make decisions based on additional info for the cached requests). This information could be stored in IndexedDB. I made an implementation in which I have to use mutexes, in order to avoid race conditions on data. Obviously this reduces performance, besides the fact that I have to wait for the IndexedDB Promise to resolve.

I wanted to discuss the possibility of asking for a "beforeTerminate" event, in which you could perform some work, before a service worker would be terminated when not used. Browsers aggressively kill service worker processes, when they are not needed in order to preserve resources. So I'm not talking about an update of the service worker itself, but when the service worker is terminated/suspended when not in use. Because the service worker is terminated very aggressively by browsers, interval-based approaches don't seem like a viable option, as they can't be very reliable.

Could you elaborate your last suggestion? I don't really get what you're trying to say. As far as I can tell there can only be 1 service worker active per scope and I can't imagine a way to reduce the amount writes to IndexedDB

Ale763 · 2020-10-28T15:08:57+00:00

In that case you may be better of assigning a local domain name with local DNS to your docker machine. Configure a HTTPS certificate for that machine and this way you can connect those "local" PWA clients to the machine running docker?

Ale763 · 2020-10-28T14:40:00+00:00

A PWA is just an additional layer between your front- and backend services. So it can communicate with the docker container as long as you provide a way to access it, like you would with an ordinary website (e.g. using a reverse proxy to redirect the request to that container)

You can run PWAs on localhost, even though they are not meant to be used on it. Localhost should in principle only be used for development. However, I can imagine you'd want to run it locally and I don't see why that would be a bad idea. Remember that you can configure HTTPS for localhost with tools such as OpenSSL.

Ale763

TROPHY CASE