Malleable VIs...

[ciozi137]

I'm thinking that Remote Control should not be a VIM... Also the others?

[ciozi137]

[ciozi137]

revert Read and Write.vim, Enum to String.vim

[ciozi137]

Remote Client.vim

I've decided that Remote Client.vim will remain a malleable VI. There are several changes for the next release (v1.14):

• Send and Receive.vi is no longer a malleable VI. I don't think that it made sense to be one.
• no longer calls Local Client.vi(m). If you want a Local Client, don't call Remote Client.
• there is now preprocessing inside Remote Client.vim (Validate API Method.vi) to determine if a valid command is being sent
  • Validate API method is called outside of the Error case structure. If the command is not supported Validate API method will return an error...
  • It is expected that child classes will override Get SMO Public API.vi with the list of API methods that they support.
• Returns are processed with JSON-RPC.lvclass:JSON to LVtype.vim. This method is intended as a replacement for Instrument.lvclass:Variant to LV Data.vim

Local Client.vi

• No longer a malleable VI. My philosophy is that Local Client will be used to handle internal messages (e.g. SMO to SMO). As such I would like to give greater control to the developer to handle formatting of their data. For example they may not want to format their payload as JSON because of the performance hit.
• Notice that Local Client.vi is basically a fancy wrapper for Instrument.lvclass:sendMessageToProcess.vi with a mailbox for receiving message responses: If you don't need or want a response then you can just call sendMessageToProcess.vi directly.

[ciozi137]

Remote Control.vim --> Remote Control.vi. Let the calling VI handle datatype....

[ciozi137]

• Remote Control is no longer malleable.
• Somewhere the spaces got removed, but now they are again Local Client.vi and Remote Client.vi.
• Note that Client.vi is a new dynamic dispatch VI; the parent method selectively calls Remote Client or Local Client ()Issue #102)