Adding UI for entering, editing, removing from the possible list of Secondaries (PRIMARY)

[mmehr2]

This is a feature intended for the Primary version only (the main differentiation between the two).

UI requirements listed elsewhere. This is for the internal support in my CustomComm class. Need to make sure the Secondary address comes from at least a user-editable CONFIG file and persists, for now.

The RemoteDialog class seems to be able to be pressed into service. More thought needed.

[mmehr2]

I am currently using the RemoteDialog without changes.

For Login (setting up the local channel), I am using the Username as the local DeviceName. This is set as the SECONDARY name as the code goes into immediate listening mode.

For the remote DeviceName to choose for connecting, I am using the Username field of the Remote Installations section. This is the one that shows up in the list box after the user enters it.

Mostly, the Login and Connect buttons behave as desired. There is a behavior that no longer makes sense with Pubnub (that did with Google Talk). The Login button switches to Logout only after the Connect button has returned successfully. It makes more sense with my setup to have Login/Logout be allowed immediately, and then have Connect/Disconnect operate "on top of" that. Currently, I don't think you can get a Disconnect without a Logout. The user may want to operate with several different remotes in one session of usage.

Internally, I have added another file to the system for user-editable configuration. This file is currently called the MSW.INI file (NOTE: the user can't see the .INI unless they enable the capability, and most don't - consider a name change to this file). This file contains various configuration info for the Remote subsystem.

First there are the Pubnub security keys (as plaintext hex ASCII), so they can be copied by the customer directly from their Pubnub account. After discussions with Pubnub, they wish us to use a single pair of these for the project, so tracking and billing can be done directly with one company (ECS Video). In that case, it is still probably useful for ECS to have this accessible for possible modification, but maybe in a different place than where the customer can see/use it too. (Two files and hide one? Or just don't document it.)

The same file contains configuration strings for the CompanyName (used to complete the channel name) and the default Devicename. The end user can configure these to whatever they wish. They are internally adjusted if any of Pubnub's "reserved characters" are used. Currently, the algorithm is found in the source code in the file PubnubComm.cpp around line 150 in the function remove_invalid().

My channel naming convention is to add the prefix "MSW-" to the CompanyName above, followed by the separator "-" and the DeviceName, whether local (for SECONDARY listening) or remote (selected by PRIMARY for connection). Currently, the two DeviceNames come from the UI, while the CompanyName is specified in the INI file.

When security is added using TLS (perhaps for the file transfer feature), the keys will probably need to be kept here as well, unless there are better alternatives available on Windows 10. Direct registry editing is probably not a good thing to mandate for customer usage, so some kind of configuration in the installer program might be desirable. The installer was not included in this project, however. Contact ECS for the particulars.

There is also the need for some end user configuration around the use of a Proxy system in connecting to the Internet. This code is not currently included in the project, but may need to be added for certain customers.

[mmehr2]

What makes this an enhancement is the need for this to operate only on the PRIMARY version of MSW-R. Eric wants the Remote Dialog to be disabled and/or hidden on the SECONDARY version, to be sold to the customer's satellite studios/offices. There will be one PRIMARY version (initially) sold to them that will be in the operators' offices (maybe more later) and that should be sold for more.

In line with this, there is a need to further differentiate the SECONDARY such that its keyboad/mouse operations are disabled when it is in a Remote conversation. This points up the need for an operational protocol to Start/Stop the connection by a message conversation. The conversation should be rejected if there is one already going on. (This will be needed the first time there are two PRIMARY installs of this program that could contact the same SECONDARY device.)

These clarifications need to be added to the Requirements document, as well.

[mmehr2]

Work Tasks: Scope: Primary (value added)

• [ ] - Ignore Login/Logout on Toolbar when in Dialog (see Issue #20 )
• [ ] - Make sure it works as desired
• [x] -- Logout allowed if logged in, if Connected has more work
• [x] -- Connect/Disconnect usage differs from what it does now
• [x] -- Make sure buttons are grayed out during operation of command and turn on when complete
• [x] -- Add more detailed error/status area than one-liner at bottom of screen.
• [ ] - Add edit boxes for Company Name (?) and Device Name
• [ ] - AddRemote dialog only needs a name field, no credentials now.
• [ ] - Need validation on input for some fields (?)

Sending Machine Preferences:

• [ ] - Need a message to send these to the Secondary at the start of Prompt mode.
• [x] -- Add Prefs Dialog mechanisms to serialize and de-serialize the settings from string form.
• [ ] -- Send a new Primary message at start of scrolling containing the serialized preferences
• [ ] -- New message response to de-serialize the received string and save the settings as if the user had pressed OK on the Secondary machine's preferences dialog

[mmehr2]

• There is a need for communicating Secondary device name changes to the Primary. Currently the channel name for comm is tied to the device name given at startup. We should enforce no changes to the channel name if the device name is changed, or ask the user if they want us to communicate it to the Primary. (They can do it by normal email for example.) If it is desired to automate this, Secondary needs to know which Primary to contact, then sends a message on that channel of its Name Change, giving the old and new Device names. (Channel name must stay the same.)

• Or we need to just use UUIDs as unique channel names for private comm. These should not change. If they do, the Primary needs to be updated manually, the UI needs to have the Device Names as well as what the UUIDs for the Secondaries are, and we need a whole mechanism of self-discovery. For example, if a Primary doesn't know a Secondary's UUID, we need a Company-wide channel (name using the Company name, which if it IS a company name, shouldn't change) that can be used for a request for UUID on Device Name X. On receipt of this message, all machines look and the one with that Device Name replies with its UUID/private channel name. Unfortunately, listening on a second channel may double the subscription traffic unless we use a Channel Group. Is this an included feature on Pubnub? More complexity!