Decide on `add_alias` API

[epage]

An unresolved item from #169 was how add_alias should adapt to the file type being used or not.

From the issue:

I think we talked about defaulting default_baud_rate to None.

• If its None and a file type that doesn't need it, we just pass 0.
• If its None and is file type that needs it, we throw.
• If its not None and a file type that doesn't need it, we error.

Granted, there are pros/cons to this. I'm still torn on it myself.

[jashnani]

@lilesj: We should consult with Jason Smith on this because the underlying implementation/behavior of add_alias can be complex.

[d-bohls]

@sjasonsmith

Jason,

Can you give your input on this change? Is it worth adding the extra handling around our calls to nxdbAddAlias64?

I interested in your thoughts on this. As for me, I'm concerned about adding file-extension-based restrictions that would need to maintained separately outside of the driver. I'm leaning towards just continuing to let nxdbAddAlias64 fully handle the DefaultBaudRate parameter.

[sjasonsmith]

NI-XNET 17.5 made nxdbAddAlias64 more predictable, with changes both to behavior and to documentation. With older versions of NI-XNET, it was difficult to know exactly which behavior to expect for any given set of inputs. The changes sought to strike a balance between making the interface easier to define, and avoiding breaking existing applications.

Some important notes from the 17.5 documentation to consider when implementing any extra logic around it:

If this call replaces an existing alias with the same name, the previous default baud rate will be retained if this value is set to zero (0).

This means that a missing baud rate isn't always a problem. I think this is an argument for Ed's first option.

With regard to those properties set when adding an alias from the database editor or the LabVIEW API, related to issue #213 :

When replacing an existing alias with the same name, special rules apply. The alias may have additional properties associated with it, which are added when the alias is created through the XNET Database Editor or the LabVIEW API. These properties are not configurable when adding an alias using this function. These include the CAN FD ISO Mode, default FD baud rate, and ignore application protocol properties. These properties will be retained from the existing alias, and will be used with the new alias if applicable.

If you wish to discard all properties from the previous alias, the alias should first be removed with a call to nxdbRemoveAlias.

[sjasonsmith]

I just realized Ed was documenting three bullets on one solution, not three different options. Based on my earlier response, I think it would be most appropriate to just default the baud rate to 0, and pass it down to XNET to decide whether to generate an error or not.

It would seem preferable for the Python API to not know about database file types at all, as that is one aspect of XNET which evolves over time. Making this code filetype-agnostic should reduce maintenance if new types are added in the future.

[d-bohls]

I agree with that assessment, @sjasonsmith. Also, in LabVIEW, default_baud_rate is an optional parameter with a default of 0. Here's my current plan:

• default_baud_rate is an optional parameter that defaults to None
• A default_baud_rate of None is coerced to 0

So here's what happens with currently supported database types:

• For .xml, .arxml, and .ldf databases, the default_baud_rate is just always ignored
• For .dbc and .ncd, a positive int for default_baud_rate will be used if the user doesn't specify a session's baud rate.
• For .dbc and .ncd, a default_baud_rate of 0 or None means the user must specify a baud rate for sessions, else the driver will error when they try to use the session.

@epage Does this sound like a reasonable compromise?

[sjasonsmith]

For .dbc and .ncd, a default_baud_rate of 0 or None means the user must specify a baud rate for sessions, else the driver will error when they try to use the session.

Unless they are replacing an existing alias, in which case it will inherit the value from the old alias.