Re: Service worker F2F meeting - 26th Jan - San Francisco

[Conrad Irwin]

I'd be interested in attending as a relatively mute observer. We've been
using service workers for a while now, and I'd like to get more involved.

Conrad

On Monday, January 4, 2016, Jake Archibald  wrote:

> Since many of those involved in service workers will be in town for the
> web components meeting on the 25th (
> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md)
> we're having a service workers meeting on the 26th.
>
> The meeting is being hosted by Mozilla
> https://www.mozilla.org/en-US/contact/spaces/san-francisco/.
>
> I've created an issue to discuss agenda items
> https://github.com/slightlyoff/ServiceWorker/issues/806.
>
> We have a couple of spaces left if you're interested in participating,
> although we're going to spend the majority of the time on low-level details
> and spec.
>
> Cheers,
> Jake.
>

Re: Indexed DB + Promises

[Conrad Irwin]

One of the things I like about the WebSQL API is that the transaction
aborts if any queries fail or if any callbacks throw errors. This way the
whole transaction can be handled as a promise easily, which provides nice
abstraction to the calling code.

It comes at the expense of each individual operation being promisified,
each operation still takes a callback so that you know for sure when code
is 'done' handling a result (it's hard to tell when a promise is done
because .then can be called multiple times and at any time).

I would like to see any work on IndexedDb promises go the same way:

1. Figure out how to tell if a transaction succeeded or failed.
2. Wrap the transaction in a promise, so that code can be structured at a
high level with promises.
3. (Optional) represent each request as a promise, if that's compatible
with goal 1.

If I remember rightly it's hard to do 1 in general with the current
non-promise based API, so any change to make the  API more promise
based should first address that.

Conrad




On Tuesday, September 29, 2015, Jake Archibald 
wrote:

> I agree with Jonas, I'd like to see IDBRequest and IDBTransaction be
> thenables. This could be done by having a hidden promise, and having
> .then/.catch proxy to the same methods on the hidden promise.
>
> We just have to get over the throw/reject thing.
>
> On Tue, 29 Sep 2015, 23:16 Jonas Sicking  wrote:
>
>> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola > > wrote:
>> > This seems ... reasonable, and quite possibly the best we can do. It
>> has a several notable rough edges:
>> >
>> > - The need to remember to use .promise, instead of just having
>> functions whose return values you can await directly
>>
>> One way that we could solve this would be to make IDBRequest a
>> thenable. I.e. put a .then() function directly on IDBRequest.
>>
>> > - The two-stage error paths (exceptions + rejections), necessitating
>> async/await to make it palatable
>>
>> I'd be curious to know if, in the case of IDB, this is a problem in
>> practice. I do agree that it's good for promise based APIs to only
>> have one error path, but IDB is pretty conservative about when it
>> throws.
>>
>> Do people actually wrap their IDB calls in try/catch today?
>>
>> Certainly throwing at all isn't perfect, but is it a big enough
>> problem that it warrants using a library?
>>
>> > - The waitUntil/IIAFE pattern in the incrementSlowly example, instead
>> of a more natural `const t = await openTransaction(); try { await
>> useTransaction(t); } finally { t.close(); }` structure
>>
>> I'm actually quite concerned about using a t.close() pattern. It seems
>> to make it very easy to end up with minor bugs which totally hang an
>> application because a transaction is left open.
>>
>> But maybe developers prefer it strongly enough that they'll use a
>> library which provides it.
>>
>> > I guess part of the question is, does this add enough value, or will
>> authors still prefer wrapper libraries, which can afford to throw away
>> backward compatibility in order to avoid these ergonomic problems?
>>
>> Yeah, I think this is a very good question. I personally have no idea.
>>
>> / Jonas
>>
>>

[service_worker] Notification constructor

[Conrad Irwin]

Hey All,

Apologies if this isn't the right place to ask about the service worker
spec.

I've been implementing some things with service workers, and it's a little
bit frustrating to have to use

  self.registration.showNotification(hi!)

instead of the more normal:

  new Notification(hi!)

Is there a technical reason that service workers can't call the
Notification constructor as usual?

It would be nice for two reasons:

1. I could use the same wrapper library in-page and in-worker,
2. I'd be able to call .close() on the returned Notification.

Thanks,

Conrad

[cors] Ability to read Access-Control-Expose-Headers

[Conrad Irwin]

Hi all,

Is there a reason that Javascript cannot read the Access-Control-*
headers in CORS?

In particular I was trying to work around a bug in Firefox [1] that
means that .getAllResponseHeaders() doesn't get all response headers
for CORS requests. It seems that the nicest way to do this would just
be to iterate over the list of simple-response-headers, and the
contents of the Access-Control-Expose-Headers header.

Unfortunately, I'm not able to read the Access-Control-Expose-Headers
header, because it was not exposed in the
Access-Control-Expose-Headers header :).

In general it seems like a useful introspection mechanism — it would
allow applications to distinguish between this header was not set
and I am not allowed to read this header. It also seems that it
would be useful to be able to read the Access-Control-Allow-Headers,
and Access-Control-Allow-Methods headers so that the javascript
application can adjust its feature set based on what the server will
allow.

Conrad

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=608735