Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The way to integrate the API without depending on ECMAScript realm. #217

Closed
yoshisatoyanagisawa opened this issue Feb 14, 2024 · 3 comments · Fixed by #219
Closed

The way to integrate the API without depending on ECMAScript realm. #217

yoshisatoyanagisawa opened this issue Feb 14, 2024 · 3 comments · Fixed by #219

Comments

@yoshisatoyanagisawa
Copy link
Contributor

What is the issue with the URL Pattern Standard?

In, 4. Using URL patterns in other specifications, there are two ways to integrate the URLPattern API. However, both of them depends on the ECMAScript realm.

Considering the integration with the compression dictionary transport and the ServiceWorker static routing API, it may not be feasible because they may not have the ECMA realm on the pattern creation or execution.

We need the way to integrate the API without the realm dependency.

@yoshisatoyanagisawa
Copy link
Contributor Author

@pmeenan @horo-t @sisidovski FYI.
I suppose the compression dictionary transport and the SW static routing API do not want URLPattern to depend on the realm.

@sisidovski
Copy link
Collaborator

@jeremyroman If we could compose pattern without "new URLPattern" in the step 2.1 and 3.2 build a URLPattern from an Infra value, can we drop realm here?

@domenic
Copy link
Member

domenic commented Feb 14, 2024

The correct solution to this is kind of annoying and mechanical.

You basically move everything that is currently associated with the URLPattern object to a separate "URL pattern" struct. These are manifestly realm-independent.

Then you update all the algorithms possible to operate on the URL pattern structs. Especially, the ones that are exported from this spec for public use by other specs. This includes creating some new algorithm, e.g. "create a URL pattern", which is a variant of "initialize a URLPattern" which creates a new URL pattern struct from appropriate values, instead of operating on a created URLPattern object.

Then, the URLPattern object gets an internal "backing URL pattern", which is an instance of the URL pattern struct type.

Then, everything in the public API forwards to "this's backing URL pattern".

You can see this pattern in action, for example, in how https://fetch.spec.whatwg.org/#request-class lists Request as having an associated request, which is an instance of the request struct. (It's not explicitly declared as a struct, but it's the same thing.)

The fact that this pattern is kind of annoying and mechanical means that, to me, it's pretty obvious how the spec is "supposed" to work right now. But cleaning this up would be a good idea, eventually.

yoshisatoyanagisawa added a commit to yoshisatoyanagisawa/urlpattern that referenced this issue Feb 15, 2024
This is a part of whatwg#217
to make URLPattern match independent from realm.

As a first step, dependency to a URLPattern object has been
moved to a URL Pattern struct.
yoshisatoyanagisawa added a commit to yoshisatoyanagisawa/urlpattern that referenced this issue Feb 16, 2024
To allow the algorithms in the specification to be used outside of
JavaScript, we need to remove dependency to JavaScript realm.

This CL make a URLPattern object associated with an underlying URL
Pattern struct, and makes algorithms to use it instead.

Fixes whatwg#217
sisidovski pushed a commit that referenced this issue Feb 27, 2024
To allow the algorithms in the specification to be used outside of
JavaScript, we need to remove dependency to JavaScript realm.

This CL make a URLPattern object associated with an underlying URL
Pattern struct, and makes algorithms to use it instead.

Fixes #217
yoshisatoyanagisawa added a commit to yoshisatoyanagisawa/ServiceWorker that referenced this issue Mar 4, 2024
Updates in the URLPattern specification was requested during the
w3c#1701 review.

The issues for the request has been resolved:
- whatwg/urlpattern#217
- whatwg/urlpattern#218

However, during the specification updates, the algorithm names are also
updated, and adjustment is needed.
mkruisselbrink pushed a commit to w3c/ServiceWorker that referenced this issue Mar 13, 2024
…tion (#1707)

* Update link texts upon updates in the URLPattern specification

Updates in the URLPattern specification was requested during the
#1701 review.

The issues for the request has been resolved:
- whatwg/urlpattern#217
- whatwg/urlpattern#218

However, during the specification updates, the algorithm names are also
updated, and adjustment is needed.


Co-authored-by: Domenic Denicola <d@domenic.me>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants