# 12/3/2020

### Attending:

* Cary Phillips
* Joseph Goldstone
* Kimball Thurston
* Larry Gritz
* Nick Porcino
* Owen Thompson
* Peter Hillman
* Rod Bogart

### Discussion:

* Larry: The 3.0 porting guide will probably be couple of pages, as a
  separate doc. Haven't gotten to it yet.

* Kimball's new C Core:

  * The C level is just about file IO. The goals is performance,
    memory optimization, and thread safety.

  * We really won’t want to change the structure of the fie.

  * The PR includes code a "namespace" mechanism via macros that make
    function and type names configurable at compile time. Is this
    useful?

    * Similar in spirit to the jpeg library: can configure the jpeg
      library as either 8bit or 12 bit; it swaps out the function
      names so you can have both in the same namespace.

    * Kimball: we might have an application for this mechanism at
      Weta, not really sure.

    * Code readability overhead seems high. Is it worth it?

    * If we're ever going to add it, now is the time. Easiest to put
      it in at the beginning.
  
    * Cary: Our mission statement says to place a high value on
      simplicity, reliability, maintainability, compatibility.
    
    * Cary: We should include this only if someone has an actual use
      case. Otherwise, it's unnecessary complication with no
      demonstrated benefit.

    * After discussion, Kimball will rip out the macro namespace thing.
    
  * Next step is to replace the guts of the C++ library with the C
    library. Under the covers the gues will get swapped out, but the
    external C++ class API should not change.

  * Kimball: The C layer is far more strict about types. If it
    encounters garbage data it rejects the file.

* What is the timeline for the 3.0 release?

  * Cary: There is obviously a lot more work to do to even get to a
    compilable, working version, much less a thoroughly tested,
    releaseable version.
    
  * Rod: The VFX reference platform says 3.0.

  * Could there be a build-time switch between new and old? Seems
    complicated.
    
  * Alternatively, we could release more or less as is with the new C
    core there but not yet integrated into the C++ API. This would
    give access to the new code without any potentially destabilizing
    changes.
    
  * Kimball: The biggest hindrance is the threading part of the
    library. I hate that OpenEXR creates threads.  To get the maximum
    performance you’ll want to use the C layer.  We lack a C++ layer
    that makes calls threadsafe.

  * After discussion, we agree:

    * The 3.0 release will include the code reorg and bug fixes, but
      without the new C core.

    * Soon after the 3.0 release, we'll release 3.1 that includes
      the new C core as a side library. This gives access to the
      high performance, thread-safe file IO without altering the
      existing code or API. Users can access it if they want.

    * Over subsequent 3.2, 3.3, etc releases we'll migrate the C++
      api to use the new core. This is possible because the API
      won't change.

* Joseph’s Standard Optional Attributes should go into 3.0.
  
  * Joseph: I have a PR almost ready. Haven’t filled out the CLA yet.

  * Need to make sure there’s no existential conflict between
    up-vector and world transforms in the current
    implementation. Both imply things about where the camera is in
    relation to objects.

* Report from the TAC meeting on proposal for new rawtoacess project.

  * Kimball: Alex Forsythe at the Academy and I have been doing
    something similar. Would like to find a better home for the
    project.
  
  * Propose rawtoaces - a project that merges existing versions of
    code into a common library.

* Request from gregcotton for a point release that includes PR #854,
  fix to config for macOS.  Should we include other bug fixes? Where
  do we draw the line?  With 3.0 now likely in January, is that an
  acceptable fix? Cary will look at what other PR's might reasonably
  go into a 2.5.4 release.