search

elm-lang / elm-reactor

Interactive development tool that makes it easy to develop and debug Elm programs.
BSD 3-Clause "New" or "Revised" License
428 stars 63 forks source link

RFC Alternative way for serving assets and reactor internal requests #128

Open JustusAdam opened 9 years ago

JustusAdam commented 9 years ago

The Issue

Currently assets for elm-reactor html pages (at least the wrench icon, which is the one I confirmed this for) is serving assets through the url scheme "/actual/path/to/asset.fileending".

The issue is, that that is the exact same url scheme used for the regular repository content. This could potentially cause issues if a repository were to contain a file say called "/_reactor/wrench.png". I believe this issue can be trivially fixed via the use of a different url scheme for reactor internal resources through the use of url params. This would have the added benefit that matching for asset requests would be easier.

The Proposal

I propose the following general structure:

"/?resource=resource-type&path=/path/to/resource"

Example

In the case of our wrench "/_reactor/wrench.png" would turn into "/?resource=asset&path=/_reactor/wrench.png". For dynamic JavaScript it could be "/?resource=dyn-js&path=/creator/factory/value.js". Or potential future ajax folder index operations "/?resource=index-dir&format=json&path=/folder/to/index"

Since I am currently working on the reactor anyways to integrate the new fronted it'd be little more work for me to implement this. However I'd like to garner some feedback first wether the community agrees that this is a good idea and whether the proposal itself is good and/or whether people have suggestions for improvements to the proposal.

evancz commented 9 years ago

Isn't it possible that a JS file or Elm file looks at these queries and does something with them? My main concern would be that the probability of overlap with names like resources and path and format would be way way higher than with the current _reactor path.

How would you think about this risk?

Is there a way that this is handled in other similar projects?

JustusAdam commented 9 years ago

I don't know of any scripts that wildly modify href tags just because there's some query parameters in them. Which is not to say that such scripts do not exist of course. Modern Javascript communicates with html through data-... tags and classes though, I don't think it'll touch the href's.

Besides, since we are the ones developing the full stack with client and server code we'll have control over what javascript runs.

Online IDE's like cloud 9 don't have links at all, they do everything with event handlers in javascript and ajax.

Github prefixes all files with /blob/ and loads assets from a subdomain assets-cdm.github.com which avoids overlap.

I generally don't think that arbitrary javascript modifies these hrefs, since that would require non trivial knowledge about the backend or force the backend to have a particular structure which is not desired.

Furthermore since all javascript code is written by ourselves we can say for certain that it (currently) does not modify any url's on the site.

We can always make the query more specific though by adding parameters.

netaisllc commented 9 years ago

FWIW, generally, have a path (or a set of paths) that are "vendor reserved" by convention only is enough. Devs will adjust/embrace as long as the plan is reasonable and consistent.

Take for example, the RESTful data store CouchDB. The entire community knows that hostname:5984/_utils is where the CouchDB embedded management console lives, and hostname:5984/databaseName/_design is where a particular db's design documents live. In fact, we count on that. (BTW, I'm showing the default port number; it can vary...)

The point is _reactor could work, maybe _elm_reactor is better.
But all that said a query parameter scheme is also acceptable.