I assume the mention of "files" in the description is really talking about what an initial implementation might look like, not something that would be visible in the interfaces. It would be good to have an interface that could support in-memory work and, potentially, streaming.

this DM-4548 might relate, or this might even depend on it, I'm not sure.

Gregory Dubois-Felsmann, in-memory and streaming dataset falls under a different story; DM-4542. This story represents the degenerate case for getting non-local files; copy to local and provide python object to user.

Brian Van Klaveren I took a few minutes to think about this. I think this is the way to proceed, and I'll keep thinking about it too. Let's continue talking about it, eh?

for remote get:

1. define and implement Access interfaces needed by Mapper (actually CameraMapper), Butler, and possibly Repository.
2. Access will have to return one or more ButlerLocation instances, with enough information that it can be used later to retrieve the file. - refactor BulterLocation as needed to contain proper URL or whatever.
3. create Access backend to support the remote connection, file transfer, temp file storage & management (e.g. when to delete the file?)
4. one of:
   • create test mapper to use the remote
   • refactor camera mapper to use Access and use it to test (this will be a sizable amount of work, est. 10-20 story points), maybe this is something I could do in parallel)
5. refactor butler _read to use Access instead of reading files from the local filesystem

cameraMapper for non-direct access only (remove all os.path… foo) includes:

• setting up the output root
• finding parent
• finding & loading registry
• doing a backup
• looking up defects
• finding the camera (_makeCamera)