Allow to run with remote layers.yml

[gunnarmorling]

Allow --layers-config https://example.com/layers.yml.

[gunnarmorling]

@aalmiray, @hendrikebbers, this might be interesting for use cases around JavaFX and Web Start?

[aalmiray]

One question though, how would dynamic layers (plugins) work in this case? Currently Layrry assumes relative paths are linked to the basedir of the given config file.

[gunnarmorling]

Good question; one could think about installing plug-ins from remote repos, too. Triggered via an action in the application itself, e.g. like when you install a plug-in into VS.Code.

[aalmiray]

Right. We may be looking at the following combinations

LL = Local layers
RL = Remote layers
LP = Local plugins
RP = Remote plugins

LL | RL | LP | RP
x  |    | x  |
x  |    |    | x
x  |    | x  | x
   | x  | x  |
   | x  |    | x
   | x  | x  | x

[aalmiray]

The following may be used to detect if a parser supports the given URL

• the extension in the path element
• the Content-Type header

[aalmiray]

Good question; one could think about installing plug-ins from remote repos, too. Triggered via an action in the application itself, e.g. like when you install a plug-in into VS.Code.

This is another good use case for #39

[brunoborges]

This would potentially enable WebFX

[aalmiray]

LL = Local layers
RL = Remote layers
LP = Local plugins
RP = Remote plugins

LL | RL | LP | RP
x  |    | x  |
x  |    |    | x
x  |    | x  | x
   | x  | x  |
   | x  |    | x
   | x  | x  | x

Additional considerations based on the table shown above:

1. LP with RL requires resolving directory paths with a base bath. Currently in RL that base path is dictated by the location of the layers file. We can't assert that with RL. We could use System.getProperty('user.dir'), we could also accept an extra configuration flag for setting the base path. Options:

   • with LL:
   • If --basedir is given, use it as base path.
   • Otherwise use the location of --layers-config as base path (current behavior).
   • with RL:
   • If --basedir is given, use it as base path.
   • Otherwise use System.getProperty('user.dir') as base path.

2. RP require Layrry to watch over remote resources. I think this can be quite problematic. Perhaps switching from pull mode to push mode would be better to begin with. If so, Layrry requires an external notification that triggers dynamic plugin updates.

[aalmiray]

I think adding the following method to LayesrConfigLoader is the way to begin

static LayersConfig loadConfig(URL layersConfigFile)

This method will check the URL and download the resource to a temporary location (we could think of a cache option at a later point), then proceed to invoke the already existing loadConfig(Path layersConfigFile).

A few impl details:

• if the URL resolves to a file:// URI then no download occurs and the URL is transformed to Path and used as is.
• Supported URL schemes will be http and https to begin with. Additional schemes may be supported in the future (may require external library to resolve such schemes).
• If the URL's path does not define a recognizable extension (for now, does not conform to the . pattern) then headers should be inspected and check for the MIME-TYPE and use that value to declare a file extension.

[aalmiray]

Thinking in how remote plugins could be supported, application code has to reach into boot code (Layrry) to trigger a plugin refresh. What if Layrry were to open a socket to enabled this case, allowing a single command to pass through, i.e, "refresh"?

Pros:

• could be used for future commands (if any).

Cons:

• an open socket without any security nor authentication.

[gunnarmorling]

Done.