Skip to content

Latest commit

 

History

History
94 lines (91 loc) · 5.03 KB

2023-09-07.md

File metadata and controls

94 lines (91 loc) · 5.03 KB

OpenAssetIO TSC September 7th 2023

Agenda

  • Next steps for "pipeline show and tell" discussed at SIGGRAPH BoF.

    • Who is willing to talk at a high level about how their pipelines manage data?
    • 10-15 mins max
    • Ideally recorded
    • TC: Some people at SIGGRAPH were happy to talk about their pipeline, focussing on data management. We probably want a few sessions with several talks spread across them.
    • MDs: Happy to talk. Recording might be a problem, but can probably make a shareable slide deck.
    • L: Similar.
    • OS: Can synthesize something from the various studios using AYON, e.g. worst-case scenarios.

  • v1.0.0-beta.1

    • Sign-off on remaining changes
      • TC: 95% completion to beta 1, yey!
    • Polyfill or deprecate?
      • TC: We have the challenge of best supporting people writing against the API. What should we do? Three options:
        1. Do nothing, putting all the effort onto OpenAssetIO adopters.
        2. Backward compatibility with deprecation warnings.
        3. Add polyfill library to introduce backward/forward compatibility support.
      • MDs: We have to do a lot of version management in the build system anyway. Studio is all Rez. So happy to manage it.
      • L: Will OpenAssetIO follow SemVer?
      • TC: Yes, but at the moment we're in alpha so can't.
      • L: Most pipelines expect to manage version constraints.
      • TC: OK, so we won't worry about backward compatibility until v1.

  • v1.0.0 priorities

    • £100 exercise - vote here
    • OS: [w.r.t Trait versioning mechanism] Wanted to highlight how important data versioning is for our data model, especially whilst it's not finalised. It's essential from a structural point of view (as opposed to functional point of view).
    • TD: Does anyone know much about the USD proposal or OTIO's solution to versioning? Does it seem like a reasonable approach for us all to use the same solution?
    • MDs: It's very useful to have commonality, makes for much easier adoption.
    • TC: We should have a session to meet up with those teams to learn from each other.
    • TC: C++/hybrid plugins are important, but the clear winner is a USD resolver. Can anyone talk about why?
    • CR: OpenAssetIO on its own is interesting, but an Ar plugin does a lot of things, e.g. it exposes OpenAssetIO to USD pipelines, and works around using Python in pure USD Ar (letting people shoot themselves in the foot) - a USD resolver can help the transition to OpenAssetIO in a USD world. It's hard to imagine OpenAssetIO taking off without a pipeliney thing available, and USD gives that. It's hard for people to have the mental bandwidth to absorb both USD and OpenAssetIO separately.
    • MDs: Agree 100%.
    • OS: With OpenAssetIO our plugin for USD also gives access to a much bigger ecosystem.
    • TC: OpenAssetIO's USD resolver doesn't coalesce calls, do caching, or various clever stuff other people have done. What would be the minimum solution to say it is production-ready?
    • OS: Needs to be fast and handle farm use-cases, e.g. freezing references for the farm. Needs to have build scripts to easily build against different versions of USD.
    • TC: Segueing to implementing a read-through cache/sidecar feature for OpenAssetIO - is this an important part of a USD resolver? E.g. Nick at Pixar mentioned USD's "PCP" may provide a way to batch requests. Does anyone have the bandwidth to pick up that conversation?
    • MDs: Will follow up.
    • TC: @CR - did you say it would be good to have a stock resolver that does something simple?
    • CR: Don't recall, conceptually yes, but BAL may be sufficient.
    • TC: What about out-of-process Python? Katana removed it from their AssetAPI in order to unblock the UI thread.
    • MDs: Noone is likely to say yes to that until they hit the problem.
    • TC: We implemented a gRPC plugin, it has overhead (but that's dwarfed by network requests). We're interested in sub-interpreters. Would be good to hear from anyone with knowledge on this?
    • OS: We hit this problem when showing progress bars, and artists don't know whether to kill the DCC or wait for it. Using subprocesses can help.
    • CR: I feel like if you want Python don't expect it to be performant. So it's OK to postpone out-of-process Python. Maybe future CPython changes to the GIL will solve this for near-free. Already, existing custom USD Python resolvers come with baggage, so users are aware of the baggage.
    • TC: If we do the gRPC thing it's only a 1 line change, anyway.
    • CR: Suggest publicising on the Ar USD forums. Will promote in the asset WG discussions.
    • TC: Should we be cautious about annoying the USD people?
    • CR: OpenAssetIO is definitely relevant, don't think anyone would oppose discussing it. People only get annoyed when users post about specific DCC tools over and over. Everyone would love to see more Ar examples.

  • Any community interest in helping with USD?