Encapsulated or Per-node Profiles

[rhwood]

It would be beneficial to users to be able to have profiles store per-node (or per-computer) configurations, so the entire profile can be stored in DropBox, on a thumb drive, or shared across computers in some other fashion without having to reconfigure the profile on almost every use.

Working on this is at https://github.com/rhwood/JMRI/tree/multi-node-profiles

[rhwood]

Objectives of this enhancement are:

• No user interface changes other than:
  • a given profile only needs to be reconfigured on a given computer if:
    • the profile has not been used on the computer before
    • a new connection was added to the profile on a different computer and needs to be configured on the other computers
  • notification of migration to new configuration
• Existing shared user files among multiple profiles workflows will not break

The workflows I want to add support for by doing this are:

• User has issue with panel, roster, or something else, and is able to share a complete profile including configurations via DropBox with someone else. The second person is able to open the shared profile directly, configure the connections appropriately, and then work on the problem panel, roster, or something else, in as complete a context as can be shared without actually having both computers on the same layout.
• User is able to work on panel on one computer using simulators, and run the panel on another computer using real hardware without having to manually sync connection changes, or reconfigure connections when switching computers (as some of our users currently do).

[rhwood]

Currently connections are saved and read in the following manner:

• Saving:
  1. All connection settings are saved to the shared storage location.
  2. All connection settings are saved to the per-node storage location (this is basically a duplicate of the shared settings).
• Reading:
  1. All connection settings are read from both locations and are matched based on system name. Only connections that exist in the shared settings location are created.
  2. Each connection is created with access to both the shared and per-node settings. Currently the per-node settings are ignored. I think that for certain connection types, the information that needs to be shared and per-node varies, but that there are some core common bits of data (the connection userName) that should be shared and can be handled by the abstract connection configuration objects.

[bobjacobsen]

I don't yet understand how this looks to the user. Say I'm using a shared directory (e.g. DropBox) and configure JMRI on machine A. In the process I create profiles X and Y. That all works nice.

Now I go to machine B and fire the same JMRI program up, selecting profile X.

1. Does it start cleanly, assuming the same connections as on A? Or does it ask me something?

2. Now I change the settings for (one of) the connections in profile X on machine B & save. Do I get prompted at that point?

3. Finally, I go back to A and start the same JMRI program. Do I get asked anything? Does it start with the original A-saved connection configuration, the new B-saved configuration, or something else?

Thanks

Bob

[rhwood]

On 5 Oct 2015, at 10:01, Bob Jacobsen notifications@github.com wrote:

I don't yet understand how this looks to the user. Say I'm using a shared directory (e.g. DropBox) and configure JMRI on machine A. In the process I create profiles X and Y. That all works nice.

Now I go to machine B and fire the same JMRI program up, selecting profile X.

1. Does it start cleanly, assuming the same connections as on A? Or does it ask me something?

It starts cleanly if the same connections can be established. If the connections on A were simulators, or are also available on B, JMRI on B would start as if it were on A. If the connections on A were real, but are not available on B, B would present the same errors as it does now. That said, it probably should detect that profile X has not been saved on B and, after an explanatory dialog, open the preferences so connections can be set up correctly on B.

2. Now I change the settings for (one of) the connections in profile X on machine B & save. Do I get prompted at that point?

You will be prompted to restart after saving changes (no change from current state). There should be no further prompting at this point unless the SystemNames for the connections change (either by deleting a connection, adding a connection, or changing that name in a connection).

3. Finally, I go back to A and start the same JMRI program. Do I get asked anything? Does it start with the original A-saved connection configuration, the new B-saved configuration, or something else?

It will start with the original A-saved connection configuration unless the SystemNames for the connections changed on B.

There needs to be similar handling for file locations (if a file location is not in profile: or program:, it needs to be configured for on each new machine), and possibly other, not yet identified settings.

[bobjacobsen]

Thank you. The (2) to (3) transition above can go one of two ways: Maybe I wanted my changes on B to be global, and maybe I wanted them to be machine specific. (Use cases for e.g. global: A & B are actually on two machines on the same layout, and I just changed the command station ID from DCS050; I'm using simulators to develop on two different laptops, and my real hardware connection is elsewhere)

Will there be something that clues the user as to whether they're changing local vs global?

[rhwood]

Will there be something that clues the user as to whether they're changing local vs global?

As of now, for connections, I am working on making the UserName and SystemName global and everything else (that is controlled by a ConnectionConfig) local (i.e. that LocoNet / L1 exists is global, that LocoNet / L1 is a DCS100 or a simulator is local).

I don’t know if anything needs to be indicated in that case, just documented.

[pabender]

A follow up question to Bob's

What difference is a user who today has a collection of two or more homogenous ( from the JMRI perspective ) computers that share a profile going to see in the future?

These users expect any change To one system to appear on the others, as with the case of the command station change Bob was asking about.

Paul

[rhwood]

Our documentation has always stated that using a single profile between two computers is neither supported or recommended, and our statements on the user's list have been consistent with that. Our documentation is also very explicit that only user files should be shared between computers, not configurations.

It has always been an explicit design intent that a single configuration profile would support different hardware on different computers, but I am only getting around to implementing it now; users expecting an unsupported and not recommended use case will have to adjust their behavior.

[rhwood]

The on-file layout of the new configuration mechanism is contained entirely within the JMRI portable path profile:profile and uses the following files:

• profile.properties - Java properties file of preferences that are singular within a JMRI instance (for example, the port used by a server, GUI preferences, and the profile identity).
• profile.xml - XML data for preferences where the preferences item exists one or more times (for example, connections and startup items).
• jmri-MACaddress-profileId - A directory containing per-host preferences. This directory name is returned from jmri.util.node.NodeIdentity.identity(). Note that MAC addresses are used to identify individual hosts since they are the most reliable cross platform way of identifying unique hosts within Java. If this profile is maintained on a thumb drive or shared location like DropBox, there are likely to be multiple of these directories.
• jmri-MACaddress-profileId/profile.properties - Local preferences that are singular within a JMRI instance (for example the user files location and roster location).
• jmri-MACaddress-profileId/profile.xml - XML data for local preferences in the parent profile.xml file (for example, the details of connections).
  Backups from the previous four times JMRI was run and these files were changed are retained. Note that these backups are generated and rotated only the first time they are saved while a JMRI instance is running.

[rhwood]

I'm currently writing connection disablement as a shared connection attribute. Should it per-node instead?

[rhwood]

Should the JMRIClient transmitPrefix preference be per-node or shared?

[rhwood]

Should the ECOS preferences handled by unpackElement() be per-node or shared? (See jmri.jmrix.ecos.networkdriver.configurexml.ConnectionConfigXml for the list of these preferences.)

[KenC57]

Randall,

What is a node??

If you are meaning different computers, then the idea of the prefix is
layout specific and would be common to all nodes using that layout. All the
system names in the layout follow the one set of prefixes.

Now your question about the disabled or not.. Is the concept is the
different nodes (computers) running the layout files, one is the physical
layout and others are simulated?? This is where all the stuff is getting
fuzzy on what the goals are. So since I'm not clear on that I can't give a
useful suggestion.

-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

[pabender]

On Feb 23, 2016 7:51 AM, "Randall Wood" notifications@github.com wrote:

Should the JMRIClient transmitPrefix preference be per-node or shared?

If all of the nodes are talking to the same server, then the prefix needs
to be the same.

Paul

[rhwood]

This is substantially complete. Any issues with individual system connection preferences being in the wrong scope should be opened as new issues.

[KenC57]

Randall,

So what is the idea now of how the preferences are split?? I'm trying to
understand what is strictly a layout item, verses a node, verses a mode
(physical/simulated).

-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

[rhwood]

So what is the idea now of how the preferences are split?? I'm trying to
understand what is strictly a layout item, verses a node, verses a mode
(physical/simulated).

A layout item represents something on a layout (turnout, signal, etc…).

A node is an object in a network; in this issue it is more specifically, a computer running JMRI.

The preferences are split between what a node needs to know about a layout (mostly a shared idea of what layout items there are and how they work together) and what a node needs to know to connect to a layout (mostly a per-node idea of how a command station is connected to the node).