Re: What should ProvidingManager.provide() return if not supported?

Randall Wood <rhwood@...>

On 05-Jan-2020, at 09:51, danielb987 <db123@...> wrote:

LocoNet doesn't have support for analog values or string values as far as I know. So I'm going to use the LocoNet OPC_PEER command, using "SV programming format 1" and "SV programming format 2".

This means that an AnalogIO on the LocoNet needs:
* Destination address
* SV address
* Type (8 bit integer, 16 bit integer, 32 bit integer or 32 bit float)

A StringIO on the LocoNet needs:
* Destination address
* SV address
* Type (8 byte string using SV format 1 or variable length string using multiple OPC_PEER packages to send the string)

I can create a system name that has destination address, sv address and type, but I don't see the point of doing so since there is no way to auto discover analog IO or string IO on the LocoNet. I can discover OPC_PEER devices, but there is currently no way for the devices to tell their configuration of SV addresses.

My problem is not the need for a user name. My problem is that I need a destination address, sv address and type, and I prefer to not have these final to allow the user to be able to change these.
- There is no documented requirement that the system name of a NamedBean be final (there is a protocol requirement that the system name of an AbstractNamedBean be final).
- There is no requirement the NamedBean implementations extend AbstractNamedBean (there are already NamedBean implementations that don’t).
- The *only* requirement is that system names be unique within a running JMRI instance.

Also, by your design, it seems I could have two different NamedBeans that attempt to write (and I assume read) two different types of data (say 8 bit integer vs float or 16 bit integer vs variable length string) from the same device/SV. That suggests you should have a NamedBean for an IO device, not for an IO device by type of data handled.


2020-01-05 15:13 skrev Randall Wood via Groups.Io:
The requirement (and this is an *absolute* requirement) for NamedBeans
is that the user name is optional, and the system name is the only
name that’s needed.
User Names are set by the user, and only by the user, not by system
connections (unless the message in the system contains both something
that can be a system name and something that can be a user name).
This is because devices on a connection (like LocoNet) can *only* be
addressed by data encoded in the system name.
If you can’t work with that constraint then you don’t have a usable
design (especially for a device on the LocoNet).
Put another way, you can’t create a discovered LocoNet device with a
user name, because the LocoNet did not provide a user name to use,
just an address that is encoded into the system name.
ProvidingManagers are designed to work with system connected devices
to allow a flow like LocoNet traffic handler on connection “L”, sees
message from thing at address 42->reads message, determines thing is
Turnout->requests bean for turnout at address 42 (I.e. requests bean
LT42) be provided->ProvidingManager returns that bean, creating it if
If you *really* need to add LocoNet devices that can’t be provided
implement ProxyManager instead of extending AbstractProxyManager.
But I would first reconsider your requirement that user names be
assigned, since that’s not possible on the LocoNet itself.
On Jan 5, 2020, at 08:56, danielb987 <db123@...> wrote:
I'm implementing managers for AnalogIO and StringIO. I'm going to add a generic ProxyManager and a specific LocoNet manager for these.
AbstractProxyManager implements ProvidingManager, so I must add the method provide() in the ProxyManager. But I cannot create an AnalogIO or a StringIO from only a system name, so this method should always fail, at least for the LocoNet manager. What is the proper way to handle this? Throw an IllegalArgumentException("not supported") or throw an UnsupportedOperationException("not supported") ?

Join to automatically receive all group messages.