-
Quick recap of last 2 months effort
-
Beta 2 imminent.
-
Version Accessors
-
Prebuilt Binaries on github page
-
entityTraitsMethod
-
URL/Path converters
-
Moving forwards with trait versioning, C++ plugin system, api conveniences, and kRequired/kManagerDriven.
-
-
Traits and Specifications versioning
- Goals & Challenges
- Open Discussion
- Non-mediacreation external library technical priority
(Prior thinking : link)
-
What's worth a breaking change in mediacreation? (LocatableContentTrait - getUrl vs. getLocation)
-
Path to URL full-compliance niggles
- Are
\\.\
UNC paths of any importance for path->URL conversion? - Is converting a long path to a Windows non-normalised
\\?\
device path to work around MAX_PATH limit really important?
- Are
- Ayon needs to be able to store a version string of some sort inside their database
- Flexibility is very important
- From Ayons perspective, adapting to messy or difficult versioning methods is par for the course and not an issue, so long as its technically handleale.
- Dont encode a lot of meaning into the version
- Vendoring is probably expected
- Multiple traitgen types could be helpful to avoid having to setup multiple mediacreation packages, but it's not a make or break thing
- Matts idea : Could you publish a host and a manager version of mediacreation to avoid the need to vendor, that would avoid namespace collisions. General sense of "cool interesting idea"
- Confirmation that host is the right person to determine schema version in use
- Further desire to choose simplest solution, given expectation traits won't change very much.
- General consensus on the idea of providing a single method to allow the manager to query for the schema version.
- Probably need some small method to extract package id out of trait id to support multi-schema specs. The data is already there, but it should be an opaque type in theory.
- DCCs long path handling is bonkers, even separate fields inside the same applications behave differently. Would be helpful if openassetio solves that
- Probably worth effort to convert to device path for long paths.
- "complex" things like sharepath probably not worth it.
- Normalized paths "\." do happen, but not often.
- Move forward under the "single HostInterface method for querying versions" plan
- Plan to extend our URL/Path converter to detect longer paths and convert to the appropriate path type.