Zero development experience with Octoprint so please bear with me if this is a dumb question. I've used Octoprint for years with the typical USB->serial connection between Pi and printer so am at least familiar with how that all works and can imagine this is a fundamental feature of the code.
How much of an overhaul would it require to add additional methods of communication? For example, say a printer had an Ethernet port or wifi connection, with a possibly closed-source, not-documented communication protocol that nevertheless might be simple enough to reverse-engineer. Printing to that machine might require uploading the whole sliced file all at once using the Ethernet protocol between Octoprint server (Pi let's say) and the printer, followed by sending a couple g-code commands to initiate the print.
So I'm imagining that Octoprint would need to:
a) manage the ethernet connection, in an analogous interface to how it manages the serial connection now but you are dealing with a couple of IP addresses - one on the Pi and one on the printer - instead of a TTY.
b) implement the reverse-engineered Ethernet communication protocol.
c) integrate all that with the rest of the features - webcam, etc.
There might be other obstacles but right now I see communicating with the printer as the main one. Would adding support for something like this either directly, or in the plugin environment (I doubt it) be in the realm of consideration?