[Feature]: Global or IO-specific TypeConfigurator?

[rly]

What would you like to see added to HDMF?

Following up on the discussion at the end of #1016

Currently, there is one TypeConfigurator object that is passed around between all TypeMap objects.

For reading data: in NWB, when a user opens a file with an extension A, the IO object uses a copy of the global TypeMap with hdmf-common and nwb core loaded, and it loads extension A into that copy.

If during the same Python execution, another file is opened with an extension B, the IO object for that file uses a fresh copy of the global TypeMap and it loads extension B into that copy. This copy does not contain extension A.

For writing data: When a user writes an NWB file, by default, the IO object uses a fresh copy of the global TypeMap and users have generally loaded extensions into the global TypeMap. This approach is not ideal when writing/editing multiple files that use different extensions because they can interfere with each other, but rarely does anyone do that, so it has not been a problem. A user who wants to isolate their loaded extensions can call get_type_map and get_manager to get independent copies of TypeMap and BuildManager objects.

The TypeConfigurator manages a single dict with the configs for all namespaces. Loading a new config file updates that dict for each namespace described in the file, and the config can be cleared.

Should IO objects interact with TypeConfigurator in the same way as TypeMap, where a copy is created and modified?

Principally, I think different IO objects should be able to have different TypeConfigurator objects without having to reset the global one. But, that would be confusing (understanding TypeMap and managing separate TypeMap objects is not intended for the average user). And right now it doesn't matter, because I believe TypeConfigurator performs validation only on write and using multiple IO objects that involve different extensions is a rare use case. We also do not totally know how this TypeConfigurator will be used. So, I think we need not change the behavior unless an issue comes up. I'll close this issue, but we can use this space to discuss.

What solution would you like?

None

Do you have any interest in helping implement the feature?

No.

[rly]

cc @mavaylon1 @oruebel