consult page context when resolving asset references

[WardCunningham]

This Frame says its subject page can't be found when it is clearly identified in the Assets plugin below.

http://wiki.dbbs.co/framed.html

The Frame plugin should use markup that more directly instructs the construction of reference urls. The CORS restrictions and associated security implications need to be thought through carefully. But the success of Frame and Assets will depend on our unique insight into sharing that is not widespread in the general (and possessive) web environment.

Perhaps the markup could use keywords to distinguish intentions

ASSET framed/frame.html

rather than the relative reference used

/assets/framed/frame.html

Once the proper logic has been developed it might make sense to incorporate it into the SiteAdapter API and thus encourage reference consistency across our suite of plugins. Improved asset handling in the Image plugin is right behind Frame in this regard. Please note, @paul90.

[dobbs]

There are indeed interesting consequences for the way we share. I edited that item to include the protocol and domain name:

https://wiki.dbbs.co/assets/framed/frame.html

Here's how it looks as an external page: http://ward.asia.wiki.org/wiki.dbbs.co/framed

And by contrast, here's how it looks as a local page: https://wiki.dbbs.co/view/framed

I further experimented by visiting that page without https: (http://wiki.dbbs.co/view/framed) and learned that firefox enforces cross-origin policies even though both the main page and the framed content are under the same domain name. The protocol puts them in separate origins.

I like your suggested markup. It allows us to smooth over these cross-origin wrinkles.

[WardCunningham]

Here is the code I use to construct the sharing context that controls what assets will be shown by the Assets plugin.

https://github.com/WardCunningham/wiki-plugin-assets/blob/9a642fb06922b803478a21dee5f6c1a7e5b110f6/client/assets.coffee#L7-L18

The Frame plugin could ping each site in context order until it finds the first available version consistent with our sharing semantics. As you point out, there is no guarantee that the browser will grant the chosen file sufficient privilege to run.

I plan to add to Assets some simple click that will copy a remote asset to the origin for logged in users thus elevating the file's privilege. This will be as if the user downloaded the remote file and then uploaded it to their own collected assets. I've been slow to implement this because I haven't decided what the click should be or how progress in the download should be shown.

[dobbs]

Rather than expanding the frame markup with knowledge about assets, I've opted to prevent authors from using site-relative links. I'm not opposed to expanding in that direction, but prefer to fix this immediate behavior more simply for the time being.

[dobbs]

Today's work on issues #2 and #4 remind me that frame plugin would still benefit from working better with assets plugin.

[paul90]

It was also be nice to be very nice if site-relative links could include plugin paths, such as /plugins/journaltools/test.htm.

This will allow frame based tools to be bundled into a plugin for distribution. Rather that rely on some central source, and all the problem come with that (such as the http / https schism).

[WardCunningham]

I see that our plugin client code is fetched via similar paths.
http://trails.ward.asia.wiki.org/plugins/map/map.js

But about pages don't seem to be qualified other than by page naming convention.
http://trails.ward.asia.wiki.org/about-map-plugin.json

The Datalog plugin extends this routing with a server-side plugin that offers now-relative addressing.
http://found.ward.bay.wiki.org/plugin/datalog/esp8266-datalog/day/0

In this last case logs are written to a plugin and page specific location in the assets folder.
plugins/datalog/esp8266-datalog

These files can be directly addressed through our assets mechanism.
http://found.ward.bay.wiki.org/assets/plugins/datalog/esp8266-datalog/2021-08-01.log

We see a number of different cases here, all related to a plugin one way or another. Paul's suggestion is consistent with all of them while while rightfully segregating plugins, unlike about pages. We might go further and extend an open ended route for related content such as cooperating css and js files.
/plugins/journaltools/assets/test.htm
/plugins/journaltools/assets/test.css

Here assets refers to plugin specific assets installed along with the plugin. Assets would be an additional route in wiki.server that would be restricted to one level and be shipped with cors headers.