search

w3c / push-api

Push API
https://w3c.github.io/push-api/
Other
144 stars 40 forks source link

Add bytes() method for reading bytes into a Uint8Array #369

Closed bakkot closed 1 month ago

bakkot commented 2 months ago

Edit: Replaced by https://github.com/w3c/push-api/pull/370.

The Fetch API is getting a Uint8Array-returning bytes() method alongside its existing arrayBuffer() method, following the principle that APIs should generally vend byte buffers as Uint8Arrays.

This PR makes the same change for PushMessageData, which has its own distinct arrayBuffer method.

I'm assuming this is uncontroversial given the support from the three major implementations for doing this on Body, but I can open an issue and solicit explicit support separately if you'd prefer. I'll write tests if I get a signal that this is able to go forward.

It's unfortunate that getKey and applicationServerKey vend ArrayBuffers instead of Uint8Arrays, but it's too late to fix those now.

Implementation commitment:

Preview | Diff

bakkot commented 2 months ago

I couldn't find any existing tests to extend here, presumably due to https://github.com/w3c/push-api/issues/365. So I haven't written any tests for this. Happy to do so if there's a way to do it.

marcoscaceres commented 1 month ago

Pinging @martinthomson and @beverloo for input and additional implementer support.

This is implemented in WebKit (thanks @annevk)

@bakkot, argh... small blocker on IPR, as this is substantive contribution. I'll need you to "make a non-member patent licensing commitment" unless you somehow join the working group. I'll see how we make that as painless as possible (hi @siusin, can you help us!).

bakkot commented 1 month ago

Signing such a commitment may be problematic since I do work for a web technologies company which is not a W3C member, even though this work was not done on their behalf. Given that this PR is basically trivial and involved no decisions, I'd prefer not to bother the lawyers just for this. I am happy to close it and let a member make an identical PR if it really can't be marked as non-substantive.

marcoscaceres commented 1 month ago

@bakkot, ok... sounds good.

Coincidently, I had the same idea! 😜 https://github.com/w3c/push-api/pull/370

bakkot commented 1 month ago

Sweet, thanks.

Closing in favor of https://github.com/w3c/push-api/pull/370.

marcoscaceres commented 1 month ago

Thanks for doing the actual work bakkot!

anssiko commented 1 month ago

This issue was brought to my attention.

I believe @martinthomson in https://github.com/w3c/push-api/pull/369#pullrequestreview-2065384255 was alluding to https://www.w3.org/2003/12/22-pp-faq.html#non-participants

If joining is not an option, an alternative mechanism available is https://www.w3.org/2023/Process-20231103/#contributor-license

As per the W3C Patent Policy it is generally not appropriate for a WG participant to take a substantive change proposed by a non-participant and merge it on behalf of the non-participant to a document intended to become a W3C Recommendation. This can be seen as a red flag from a Patent Policy perspective. My recommendation is to consult the W3C Team to get this addressed properly. I believe @plehegar is in the best position to help you with that.

bakkot commented 1 month ago

This PR was not merged and can therefore be regarded as merely making the team aware of a change to an upstream API (i.e. the WHATWG Body mixin), since the API here is generally following the shape of that upstream API. Surely it is not the case that when an outside party makes the team aware of a change to another specification that requires said party to sign a patent commitment before that information can be acted upon?

@marcoscaceres's PR implements the corresponding change in exactly the way I would have because there are no possible decisions about this change, but it was his PR which landed, not mine.