23rd October, 2019
Attending: RyanW, JoshM, WardF, JohnK, Stephan Saalfeld (20:09), TonyT (20:20)
-
Deliverables & deadlines
-
Current setup
- Someone at Mt. Sinai and the rest to Quant*
- SciPy: share accommodations?
- Overhead for NumFOCUS and Mt. Sinai
- Cf.
- John: Quant’s Ralf, community outreach
- Stephan: like ITK’s MattM
-
Stephan:
- V2 backend worked on during the summer
- V3 looks to be a subset of N5, can coexist for a while
-
Ryan:
-
Leave spec related things
-
Implementation best-effort (stretch the goals; towards the end)
-
More towards spec designers (hard to get external person)
-
Josh: but perhaps for implementing the TCK
-
John: sprints together to focus? (another version)
- NumFOCUS can take reimbursements
-
-
10:30 finish up? John: more!
-
To cut/change:
-
Cut Julia [2.2]
-
C++ [2.4] becomes C/C++
- Josh: may need to split NetCDF library to work like N5
above
- Stephan: v3 isn’t layered as needed by C or Java. Can’t
build on top. Would love to see more supercore, core, then the other stuff.
-
Or perhaps we’re just saying, “Extensions are different stuff”
-
E.g. compression schemes - uses numcodecs but API is clear (Mem in; Mem out). Great.
- But: Filters in V2. Unclear how they are
parameterized, named, etc.
- But: Filters in V2. Unclear how they are
-
Chunk storage in V2. Struct formatting language. Can build new types. Makes sense.
- But: In V3 we don’t have this. Can’t do the
var-length chunks.
- But: In V3 we don’t have this. Can’t do the
-
Attributes interface: spec says “JSON”, but extensions are possible, and then there’s no common interface.
-
-
TBD: in first couple of months.
- John: extension API? Will come. SS: Not natural for
Python thinking. JK: but MutableMapping is one counterexample.
- Q to Ward: interface for C? WF: can speculate but Dennis
isn’t here.
- Josh: may need to split NetCDF library to work like N5
-
Josh: cut some of governance (do that via the community)?
- Cut [3.1-3.3]
-
Josh: happy to keep 4.1 & 4.2
-
-
-
One vs many discussions (Josh) - 20:48
-
Various people are asking: Zeiss, Napari, Fiji, etc.
-
Stephan: HDF5 has less problems than a tarball (cf. N5/BDV)
-
John: “just implement mutable mapping”
- Josh: is the proposal that add a HDF5 storage and them them to
use it? (i.e. what communities like BDV, OME, NetCDF are already looking to do)
- John: there are some backends. Don’t know what works for their
use case. Need to do benchmarking. Perhaps something for the position to do.
-
Stephan: to let someone be able to do it.
- (Tabling Python angle for next time)
-
-
Next meeting
-
John: Re-do doodle?
-
Stephan: don’t need to also be there
-
Ryan: happy to do every two weeks right now
-
Record?
-
-
AOB (likely tabled)
-
Roadmapping
-
Any ongoing issues: permissions, etc.
-