Requesting a new getter for a fully resolved URIs for the resource API

[nex3]

Currently, the Resource.uri property in the VM's implementation of the Resource API returns the original URI passed to new Resource(). This isn't useful in the common case of passing in a package: URI; the point of having a uri property at all is to use the VM's logic to return the concrete path of the resource on disk (or potentially over HTTP), so that it could be referred to in a way that's comprehensible outside the Dart ecosystem (e.g. file:///path/to/pub-cache/hosted/pub.dartlang.org/package-1.2.3/lib/src/resource.txt).

[sethladd]

cc @lrhn

The docs for the uri getter say:

The location uri of this resource.

This is a Uri of the uri parameter given to the constructor. If the parameter was not a valid URI, reading uri may fail.

Since the uri getter returns the URI set in the constructor, it sounds like this request is about a new getter for a "resolved URI"

@nex3 can you let us know how this is blocking something you need? This issue is marked High, so I presume that means this breaks something that exists now, or blocks something we need to launch. Thanks!

[nex3]

@sethladd I think my original issue title was correct. It's my understanding that the intent of the uri getter is for it to be fully-resolved; there's not a whole lot of use in a getter that always returns a value that the user already knows.

[lrhn]

The uri getter documentation is correct - it is the original argument passed to the constructor, parsed as a Uri (the argument is a String because the constructor is const and a Uri can't be const). It was not intended to be anything else.

The absence of a way to resolve package URIs to non-package URIs is deliberate.
There was no way to do that before, and we didn't introduce a way to do it with Resource.

We don't want to break the package: abstraction and leak the underlying storage structure. Resources are things that you load the same way you load imported libraries - you get to know the actual location (if any) of a package: library, and you also don't get to know the actual location (if any) of a resource.

For example, we don't require a deployed program to even have a location for a resource - the deployment step is allowed to bundle up resources in any way it wants to, as long as the Resource class can load them. They can be inlined in generated code, they can be stored in a database (maybe a browser preloading them) or they can use some other platform specific storage method that we haven't even heard of yet.

If you need to have a file accessible outside of Dart, that's not a problem intended to be resolved by resources - and we decided on not doing that after some thought. For example, you can't directly use a resource as a CSS file for a web page you generate, because that requires the resource to have a web-accessible location, which we can't guarantee anyway.

[sethladd]

@nex3 I re-read your original description in this issue, and it wasn't clear what use case you're trying to solve. What do you think about starting a DEP or (maybe easier) sending around a description for what you're trying to workaround/accomplish ?

[nex3]

Without the ability to find the resolved URL of a resource, the Resource API is only suitable for the simplest of use cases. It certainly doesn't cover any of the instances I've seen in practice where users have asked for access to their resources. As I mentioned before, it doesn't allow linking to resources, which is a serious problem for web apps, since you can't use it to add things like images or stylesheets to the application. It's not useful for serving assets, since it doesn't support accessing the file's modification time to produce effective caching. Users can't list available resources, they can't start Dart scripts or isolates using their resources, and in general they just can't use their resources with any API that's filesystem- or URL-based.

[lrhn]

That is all correct and deliberate.

We did not want to introduce a full resource management system for web applications - that's a far more complex problem that web applications were already solving in different ways (and that's without going into CDNs and image spriting, which web resource systems can also be using).

You can't list available resources because if the resources come from a web server, there may not be any way to list them.
You can't start a Dart script by executing a Dart executable, but you can spawn an isolate (because Isolate.spawn does accept package URIs). Starting a Dart executable is already assuming quite a lot about the platform.

This Resource object is intended solely for having non-Dart data that can be used by the program at runtime and be replaced without recompiling the program. It replaces embedding the data as String literals or other similar hacks.
It's simple, but that is by choice.

[sethladd]

Put another way: the new Resource [1] class solves a problem that user-space could not work around: loading a package: URI. A dart developer simply could not access package: URIs during runtime. Now they can.

There are many other valid use cases that the core SDK does not provide an out-of-the-box solution for, and we should continue to look for solutions to common and gnarly use cases our developers are running into.

resources with any API that's filesystem- or URL-based.

Hm, they should be able to take advantage of URL-based APIs... the Resource class will take any URL that the embedder knows how to load.

Might I suggest we start a new effort to identify more use cases that simply cannot be solved by third-party or external packages, and thus require a capability from the core SDK?

[1] perhaps Resource wasn't the best name.

[nex3]

Re-opening this based on our conversation this morning.

[sethladd]

If we had #24022 and #19430 we might not need this?

I'm tempted to close this because it doesn't sound like we plan to do this anymore. We do plan to enhance packageRoot and add a packageMap getter, which we believe are sufficient to address this use case.

Please re-open if we also need this.

[nex3]

If we had #24022 and #19430 we might not need this?

What about JS? Even if we want to implement a Resource-like API in package-space, it seems like we still need some very standard way of telling dart2js the URI from an entrypoint to its resources.

[sethladd]

What about JS?

Good question for @sigmundch . If yall decide you need to do something here, please do open a new issue for us to track, specifically for dart2js.

[sigmundch]

I also had a different view somewhere in between. However, I do not see Resource.uri as a way to resolve where packages are located, I rather see Resource as an abstraction so you can decouple the URI in the source-tree from the URI in the deployed application.

For dart2js, my thinking was that we would translate const-Resource instances removing the package: URI and replacing it, depending on the user's choices, with either the inlined content or with a relative URI where the resource can be loaded from. The new URI is determined separately (the user can either inform dart2js what the deployment layout is, or we can pick a default layout for the user). I see this as being similar to Symbol - they give you a way to refer to some names regardless of how they get mangled when you minify/deloy. Names for symbols are always selected by the compiler, while URI for resources can be selected by users.

Because you may need to expose in your app the URI to the deployed asset, I agree with @nex3 that this needs to be exposed. However, I don't have a strong preference between repurposing resource.uri or adding a new getter for it.

[sethladd]

@sigmundch would you mind opening an issue stating the problem we need to look into? I don't want to repurpose this one. Thanks!

(this sounds like it could even be a feature of dart2js?)