Updating PLR API for machine interfaces discussion

[rickwierenga]

I guess this discussion is going slightly off-topic, but since we do want to have the networked architecture soon I’ll work through it here because it might be unexpectedly related. We also have a separate thread on networking Networked interface for PLR.

overall I don’t think networking will make a big difference in terms of choosing option 1 vs 2. Options 1 and 2 are mostly about the user-facing python API and the default implementation we provide. The implementation and API design of course have to be flexible so that people can change out their own parts / make networking easy. I don’t see how option 1 or option 2 limits or enables that uniquely.

@koeng

ABCs were chosen because you could get that shared logic and implementation

This is not entirely correct.

Front ends like LiquidHandler are one implementation and not subclassed. These provide state tracking and other shared implementations. Backends like LiquidHandlerBackend are the ABC (or Protocol) that are implementations.

I chose ABCs for backends because it’s the standard for “protocols” in Python, or at least at that time. I suppose a Protocol will work fine instead of the ABC. (LiquidHandlerBackend etc.)

I chose the frontend/backend split so we can get the universal implementation + separate atomic backend commands. The backends follow an ABC (or Protocol) so they are interchangeable, the front ends (like LiquidHandler - which we are working on in this thread) are just one implementation (for now).

In this thread I want to discuss how to rework front ends for the reasons written in my first post.

@koeng

Now if deck was a Protocol, you could satisfy that interface from just a memory store with uploading a JSON, from a protobuf interface elsewhere, or from a JSON-append memory store. But because deck is not an interface, it becomes very difficult to figure out how to plug another backend in for it.

This is not just the case for Deck, which is a special subclass of Resource, but really any Resource I think. What we would need is a Protocol to go along every class in PLR, and have the PLR implementation be the one we provide. This way you can change out any part for your own.