Skip to content

[Proposal] Keep pynwb's public API signatures backend-agnostic #2188

@h-mayorquin

Description

@h-mayorquin

This is a forward-looking design note, not a request to migrate validate(). The intent is to have a referenceable place to point to when the same design choice comes up for future public functions.

I started thinking about this while working on #2187. The bug class that PR addresses is, I think, caused by the way we add backend-specific arguments as dedicated keywords on public functions.

The principle I propose for the future is that public API functions that interact with the backend should not name any single backend's vocabulary in their signature. Today validate() does not conform to this. read_nwb() does conform. The relevant near-term decision point is the planned remote-read support for read_nwb: rather than threading driver, aws_region, and storage_options through its signature the way validate() does, I think we should take a single generic backend_kwargs={...} dict and let a per-backend factory translate it (the pattern used internally by _open_backend_io in #2187). The dict shape is incidental. What matters is that the signature stays agnostic.

What do you think?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions