@akuker Any chance to get this PR reviewed soon? ;-) I would like to work on #664, #663, #660 or #619 next, but this PR should be merged first.

@akuker Any chance to get this PR reviewed soon? ;-) I would like to work on #664, #663, #660 or #619 next, but this PR should be merged first.

@uweseimet - Done!

@akuker Cool, thank you!

@rdmark You might want to add support for the SCHS device to the web UI. This device does not have any special properties, so essentially all that can be done is attaching and detaching it.

@uweseimet Thanks for the heads-up. I'm thinking of adding a new class of devices, STANDALONE, and add a new UI flow for attaching this kind of device.

@rdmark I'm not sure whether STANDALONE is an appropriate name. IMO the best way to attach the host services device is to use a LUN > 0, in order to not use up a device ID. It is unlikely that somebody would use RaSCSI just for the host services. Usually you will attach one or more mass storage devices, and would add the host services on top. Using the host services requires matching (new) client drivers anyway, and these drivers should support LUN > 0 for highest flexibility.

@uweseimet Apologies, I haven't really been following the development of this new device type closely! While attaching to LUN >0 is recommended, it still will work on LUN 0, right?

You haven't documented the usage of the Host Service anywhere yet, have you? I wonder if for future improvements, having a blurb in the manpage would be helpful (perhaps a bullet point for each supported device type, actually.) Thoughts?

@rdmark Yes, it will work with any LUN. (Remember that the protobuf interface returns information on which LUNs are supported by which device type.) But the more devices you attach, the more important it becomes to avoid using up device IDs, because some existing/old drivers only support LUN 0.

The usage from a developer's perspective is documented in host_services.cpp. A regular user only needs to know how the client drivers work, which is platform dependent. This means that user documentation has to be part of client software making use of the new features.
My realtime clock client for the Atari, for instance, is usually put into a special folder, so that it is automatically launched when booting. This is similar to a Mac extension (I think that's how they are called), which is launched when the Mac is booting. My client automatically detects the device ID and LUN of the realtime clock device, gets date and time from it, and then sets the Atari clock accordingly. So the instrucitons for the user basically say: Just put the tool into this folder, and your clock will automatically be set when booting.

@uweseimet Here is a first attempt at a Web UI for attaching the Host Service. Rather than "Standalone", here I'm using the term "Support Device" for the category of devices that the Host Service is (the only) member of. Do you agree that this is a better description?

PR in #666

BTW, are you planning to distribute your Atari host service software? I was curious if you had thought about discoverability for other Atari users of RaSCSI? For instance, the Web UI section for DaynaPORT points back to the RaSCSI wiki for more information on how to install the drivers on Mac and Atari.

@rdmark Yes, I am going to distribute my Atari client software, but not before there is an official RaSCSI release with these features. Because I also want to support printing from the Atari with the new SCSI printer device I may wait even longer, because the printer may not be part of the next RaSCSI release.
Users of my driver software should not have any problems finding the RaSCSI site. There is even a special RaSCSI-related area in my forum.

@uweseimet Well noted on your roadmap and plans to publish the software.

I've tweaked the help text and heading to make it clear that the functionality is experimental at this point.

@rdmark Well, it's experimental because there is still no release and the SCHS device is available in the devleop branch only. From the functional point of view there are no open issues with SCHS, i.e. at least with my clients (the only ones right now I assume) both the realtime clock and the shutdown feature work fine. They are not hard to test. The only thing that's a bit annoying is that if you test the shutdown feature, the Pi shuts down and you have to restart it ;-).