Rethink argument system

[michaelpb]

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)