Please take notice of #677.

I just noticed one more thing :). It would be nice if the ui was taking the supported parameters from the meta data returned by the protobuf interface. It should not hard-code input fields for "timeout" etc., but should dynamically create as many input fields as needed by the respective device. It then might use the values for the default parameters as placeholders, or might pre-fill the fields with the default values.
WIth the current approach each time there is an additional parameter for a device the ui would have to be updated.

@uweseimet I love the idea of the UI dynamically adjusting the available options based on metadata. It should be doable to a degree in the current Web UI framework, although jinja2 template capabilities may be a limiting factor.

At a glance, it seems like the ATTACH 'cmd' and 'timeout' parameters aren't exposed yet, however. Or am I looking at it incorrectly:

dmark@rascsi3b:~ $ rasctl -o
Operations supported by rascsi server and their parameters:
  ATTACH (Attach device, device-specific parameters are required)
    name: optional (Image file name in case of a mass storage device)
    interfaces: optional (Comma-separated prioritized network interface list)
  CHECK_AUTHENTICATION (Check whether an authentication token is valid)
    token: mandatory (Authentication token to be checked)
[...]

@rdmark Indeed, I missed adding the parameters. They are now present (in the current feature branch).
Note that the ATTACH information is more of a general kind, but any client with dynamic parameter handling has to use the meta data for the respective device, where the new parameters have already been exposed. These can never be missing, because they are directly derived from the internal set of default parameters.

...
  SCDP  Supported LUN numbers: 0-31
        Parameter support
        Default parameters: interfaces=eth0
  SCHS  Supported LUN numbers: 0-31
  SCLP  Supported LUN numbers: 0-31
        Parameter support
        Default parameters: cmd=lp -oraw %f:timeout=30

@bzeiss For your attention, I'm proposing a small change to RaCtlCmds.attach_image():

• Rename to attach_device()
• Instead of hard coded known parameters, it now takes a dict params in which the keys are parameter names such as file, interfaces, cmd, and timeout, while the values are values of those parameters.

The benefit of doing this is that a client can now pass any arbitrary parameter to the protobuf interface, which makes it easy to adapt when new capabilities are added to the rascsi backend. Please let me know what you think!

@rdmark When reading your latest comment I'm not sure whether you are going to add (or cannot because of framework limitations) dynamic parameter support.
Note that in your current sources the setting for "cmd" is not a valid one (anymore), because the mandatory filename placeholder is missing. In case of getting the default parameters from rascsi you would not have to bother with this.

@rdmark yes, sounds like a good idea given that the list of things you attach to a scsi id isn't always a disk image. I like the idea.

@uweseimet Yes, I'm addressing this one step at a time. :)

The first step, to make the underlying interface more flexible, has now been addressed.
Right now I'm looking into how to use Flask's request.form data structure dynamically, so that the web app doesn't have to know ahead of time the number of and names for form elements.

@rdmark Sounds good! Since the web ui is part of each RaSCSI release dynamic parameter handling is useful, but not as import as it is for my app. The app can be connected to any RaSCSI version, so the only way to suggest valid parameters is to always get the respective information from rascsi.

@uweseimet This is true, the Web UI can make certain assumptions about backend capabilities and get away with it. At the same, it reduces maintenance overhead and potential for bugs by doing what you suggest. I've updated the PR with code that dynamically creates the UI for Support type devices now, so when f.e. the PowerView display adapter gets implemented, we should get the Web UI for free, so to speak.

I decided to leave the Network device UI as-is for now, since using the dynamic option would take away some convenience functionality for picking IP and address mask.

@bzeiss Please note that the data structure returned from RaCtlCmds.get_device_types() will change as well, with the latest code. Rather than a list of strings, it is now a dictionary with device acronym and supported parameter pairs.

@uweseimet I was thinking: What do you say about having the server report default_parameters for network interfaces as interfaces=X:ip=Y:mask=Z? With this, I could standardize the Web UI for this kind of device, too.

@rdmark Yes, "interfaces=X:ip=Y:mask=Z" may be better. Currently this is "interfaces=X:Y:Z", isn't it? We can keep the old syntax for some time, but should remove it later in favor of the new syntax.
I will create a ticket for this change.