-
-
Notifications
You must be signed in to change notification settings - Fork 0
Home
A config-gen tool seriously benefits from some sort of dynamic user interface where you can view artifacts (type-specific views i.e. HTML, SVG, markdown, etc.), generate with an embedded CLI or UI buttons.
It does not need to provide text editing.
It should poll the underlying source for changes.
It should have tabs or some way of organizing the view of the source information (manual refresh capability in addition to automated). Maybe we can tie to the write events on files somehow?
It should also visually display the dependency relationship between tasks.
The plan to get here should be to use datazen in an incrementally more mature state until it's capable of producing sophisticated web development content.
- if a depending target doesn't exist, the failure mode is silent
-
consider timing each target and overall execution, figure out what makes sense to log
-
use threads to resolve dependencies
-
datazen should have a "dry-run" mode where you just see if you can generate stuff but you don't actually
- have this functionally mean that all output paths are overridden to temp ones
- use this to measure performance, execution time of basically everything...
- this should either get written to the output directory or the cache (probably the cache), or maybe even somewhere else
-
we should start building a dependency graph for debugging and visualization, i.e. instead of an "audit" operation it'd be nice to just get a view of what's up with the manifest and the state of the targets (plus dependency relationships, which files have been loaded into what buckets, what has changed, etc.)
-
We'll have to figure out some strategy to document the project. Maybe partially generated partially gleaned from source?
-
outline requirements in case we ever want to significantly refactor, re-design or re-implement (i.e. schemas, implicit design decisions and features)
- "the following types must be load-able"
- individual type definitions
- types of valid serializion formats
- global vs. partitioned loading
- dependency declarations
- types of targets/recipes
- requirements for each type of target
- requirements of the CLI w.r.t the manifest schema and desired features
-
we should produce a dependency graph (and populate with the info about what got loaded, use this as a better "describe")
For parallelizing jobs in a dependency tree (or graph), you basically can work your way to all leaf nodes by using recursion + a stack in the handler itself.
When you're finally a leaf, you should enque your work into some work dispatching engine which should block until complete
An individual storage entity should serve network clients and have an HTTP UI + API.
Load file system assets by URI?
Runtime state should be serializable
It should maybe also be an FTP server?