WarpFleet is the effort by SenX to federate a community around the Warp 10 Platform by providing a mechanism to expose and discover extensions, plugins and macro packages.
The WarpFleet Resolver is part of that effort, it provides a way to access WarpScript macros available via HTTP (or HTTPS).
Whenever the WarpFleet resolver is configured, with a list of URLs to macro repositories, a macro call will attempt to retrieve the macro from various places including from those various repositories.
The WarpFleet Resolver is enabled as soon as you have declared a list of default macro repositories. This list is set using the
warpfleet.macros.repos configuration key.
warpfleet.macros.repos = https://warpfleet.senx.io/macros
You can use any
https URL in this comma separated list of repository URLs.
If you include URLs with sensitive information such as HTTP credentials or secret path components, you should set the
warpfleet.getrepos.disable configuration to
true so this list of URLs cannot be accessed by the
WF.GETREPOS function of the WarpFleet WarpScript Extension.
WF.SETREPOS functions from this extension allow you to modify the list of repositories accessed by the resolver. In order to limit which URLs can be added, a validation macro can be configured using
warpfleet.macros.validator = validatorMacro
This configuration specifies the name of a macro which will be called with a URL on the stack and which should return a boolean indicating whether or not the URL is accepted. This macro must obviously be available locally or in the classpath used to run Warp 10, it cannot be fetched from a WarpFleet repository.
For obvious performance reasons, the resolver does not attempt to retrieve macros from the repositories each time they are called. This means that macros which were successfully retrieved will be cached for a certain period of time (positive caching), but also that macros which were not found in the attempted repositories will remain unavailable for a certain amount of time (negative caching).
The number of macros which can be cached overall is governed by the
warpfleet.cache.size configuration key with a default of 10000.
warpfleet.cache.size = 10000
Macros which are successfully fetched from a repository may use the
MACROTTL function to define how long they are valid. In order to avoid TTLs which may be too long or too short, the following configuration keys can be set to control the possible TTL values:
// Default TTL (in ms) for macros loaded from a WarpFleet repository (defaults to 10 minutes) #warpfleet.macros.ttl = 600000 // Lower limit for TTL (in ms) of macros loaded from a WarpFleet repository (defaults to 60 seconds) #warpfleet.macros.ttl.min = 60000 // Upper limit for TTL (in ms) of macros loaded from a WarpFleet repository (defaults to 24 hours) #warpfleet.macros.ttl.max =
Negative caching happens for macros which either were not found on any of the repositories, or which had errors when they were loaded.
For those two types of errors, there are TTLs which can be configured using the following keys:
// Default TTL (in ms) for WarpFleet macros which had errors (defaults to 10 seconds) #warpfleet.macros.ttl.failed = 10000 // Default TTL (in ms) for WarpFleet macros which were not found. If > 0, a dummy macro // will be generated which will fail with an informative error message #warpfleet.macros.ttl.unknown = 0
When a macro is called and the WarpFleet Resolver is enabled, the macro resolution involves the following steps:
- Macro prefix is modified according to the
IMPORTrules defined in the script.
- The macro name is looked up in the symbol table.
- If the macro was not found, it is looked up in the file based macro repository.
- If the macro is still not found, it is looked up in the macro library, i.e. in the classpath and in various jar files.
- If the macro was not found, attempts are made to fetch it from the configured WarpFleet repository URLs, in the order they were specified.
Read more about WarpFleet Resolver on the blog.