TypeString - Relates to #38
ForeignUrl - relates to #23
Current notes
More thoughts: piggy back on profile code!
Perhaps the way to think of this is "automatic conversion profiles". If no conversion profile(s) are specified, we get a default one that is the result of back-propagating all relevant arguments based on which converters can accept which arguments.
New resolver system
-
Resolver system should just use existing converter system (e.g. ExecConverter would do the same thing). Simply register a new ConversionGraph
Generates faux type strings something like: git:34fea34fe48db34,/some/path -> git:34fea34fe48db34 -> file:/some/path- Better system:
git_cloned -> git_updated -> git_file
- ResolverConverters have a `detect_resolver_type
-
All interior resources would be MutableResource, while the final would be ForeignResource
-
Converter system has the following concepts built in:
- "understood arguments"
- If any converter in a conversion path understands an argument, that argument is propagated backward to that point
- For example:
thumb.png:500x500 gets normalized to thumb.png:resolution=500x500 and for the STL->PNG conversion we'd have STL -> PNG:resolution=500x500
Original notes
-
The present TypeString argument system is not sufficient, it needs
-
Arguments need to have type checking and association with converters
-
They need to be carried through and be universally defined (for example, resolution would be understood by many converters)
-
Converters need to supply hints as to what arguments they accept (and when a graph is drawn with types with arguments, it chooses paths that include converters)
TypeString - Relates to #38
ForeignUrl - relates to #23
Current notes
More thoughts: piggy back on profile code!
Perhaps the way to think of this is "automatic conversion profiles". If no conversion profile(s) are specified, we get a default one that is the result of back-propagating all relevant arguments based on which converters can accept which arguments.
New resolver system
Resolver system should just use existing converter system (e.g. ExecConverter would do the same thing). Simply register a new ConversionGraph
Generates faux type strings something like:git:34fea34fe48db34,/some/path->git:34fea34fe48db34->file:/some/pathgit_cloned->git_updated->git_fileAll interior resources would be MutableResource, while the final would be ForeignResource
Converter system has the following concepts built in:
thumb.png:500x500gets normalized tothumb.png:resolution=500x500and for the STL->PNG conversion we'd haveSTL->PNG:resolution=500x500Original notes
The present TypeString argument system is not sufficient, it needs
Arguments need to have type checking and association with converters
They need to be carried through and be universally defined (for example, resolution would be understood by many converters)
Converters need to supply hints as to what arguments they accept (and when a graph is drawn with types with arguments, it chooses paths that include converters)