piscsi
piscsi copied to clipboard
PiSCSI
RaSCSI notifications
RaSCSI should be able to register subscribers and send notifications on certain events, to be handled by the subscribing clients. The immediate use case is the OLED Screen, to replace the current ineffective polling for device status. It could also potentially be utilized to create a dynamic webapp or native smartphone app that reacts to notifications to signal removable device ejection etc.
See discussion in https://github.com/akuker/RASCSI/issues/350 for design proposal
My suggestion is to add new REGISTER and UNREGISTER operations to rascsi. REGISTER registers a message subscriber based on the subscriber's host and port, which would be passed as message parameters. rascsi should support a list of subscribers, so that there can be multiple clients of this kind. In case of a device list change rascsi would send a message (defined in a new protobuf interface) to all subscribers. If a subscriber does not respond, rascsi may (or even should) unregister this dead subscriber automatically (immediately or after a message could not be delivered to this subscriber several times).
@rdmark When looking at this ticket again I tend to suggest to discard it, because even with a major effort it may not be possible to really get this working. IMO one of the potential issues is the handling of dead connections. When you have a subscriber the connection can be dead any time, or piscsi would be stuck in a potentially long timeout. In order to avoid that you would likely need a separate thread (likely one thread per connection) in order not to block everything else. A smartphone app as a subscriber would probably also be an issue, because in order to save power it would tend not to keep a connection alive when there is no traffic. A multi-threaded connection management as part of piscsi is IMHO error-prone and out of scope, and the piscsi stability might suffer from it.
Let's close it. I don't want to make piscsi more complex that it already is for little benefit.