There apparently was a discussion about why this particular operator had a different name.
If this is the case, we should at least document in the code the rationale for not adhering to the convention.

The rational, maybe flawed, was that it is common for people to talk about "Camera Frames" when they are they are thinking about some matrix of values that forms a picture. Camera Data Frames sounds clunky in comparison. In other cases, there is no common phrase -- e.g. people don't have a preconceived idea about what a Neuropixels Frame is.

@jonnew @cjsha the only counter argument I can see is that a "camera frame" is usually understood as something which is itself an image (i.e. which can be plotted directly), whereas in this case, this object is not by itself an image, but instead contains an "Image" field (among other metadata) which is what is used for saving and visualisation.

The above rationale is also why in other Bonsai camera packages we use the suffix "DataFrame" rather than "Frame", so this change could also be potentially more recognisable by the community (although this of course is definitely more of a subjective assessment).

@glopesdev that's true. I'm ambivalent here. @cjsha if you feel its clearer go ahead and change but make sure you do the back compatibility work in #380 discussion.

I think after working on the docs, I have an expectation about how things are named. If something catches me by surprise, I figure it's worth mentioning, but not necessarily worth changing. My expectation might not match the user's expectation.

The way to be consistent with how Bonsai does things and the nomenclature pattern then would be to change the name of operator from UclaMiniscopeV4CameraData to UclaMiniscopeV4Camera and leave UclaMiniscopeV4CameraFrame unchanged. Not every Data I/O operator needs to be suffixed by the word Data. Operators like PortStatus, DigitalInput, AnalogInput already aren't like this.

Then again, it seems practical that all data i/o operators appear when searching the word "Data"?

PortStatus, DigitalInput, AnalogInput don't appear in the list.

Then again, it seems practical that all data i/o operators appear when searching the word "Data"?

This was a big reason of why we chose to adopt the common suffix Data, as it provides a natural common filter when searching the toolbox. It helps to isolate these nodes from the configure and other operators with similar names.

Operators like PortStatus, DigitalInput, AnalogInput already aren't like this.

It seems like PortStatus could be renamed as PortControllerData since that is the device where it comes from.

As for DigitalInput and AnalogInput see the discussion on #103 about the AnalogIO device (same point applies to the DigitalIO device).

This concept of matching a device to a single data stream is embedded in the ONI standard itself where each device can have at most a single stream for reading frames from device to host, and at most a single stream to write frames from host to device:

• ReadFrame
• WriteFrame

I guess we could have used Read and Write as suffix for all devices, in which case we would naturally have AnalogIOReadData and AnalogIOWriteData instead of AnalogInput and AnalogOutput.

This points to an idea for a compromise convention which is simultaneously more informative and backwards-compatible:

1. If a device only has a read stream, and no write stream, call the data node: DeviceData
2. If a device has both read and write streams, call the read source DeviceReadData and the write sink DeviceWriteData.

Using this convention you could leave most devices as they are and rename the following operators:

• AnalogInput as AnalogIOReadData
• AnalogOutput as AnalogIOWriteData
• DigitalInput as DigitalIOReadData
• DigitalOutput as DigitalIOWriteData

The convention is informative since when you see a node called simply Data you would immediately know the device has no write stream. Also just writing "Data" in the toolbox still picks up the ReadData and WriteData suffixes since "Data" is part of it.