If shebang in generated argrelay client or server exceeds 127 chars, it fails to start.

The verification should be automatic: https://stackoverflow.com/a/10813634/441652

Selection of some data_envelope-s may provide (compute-able) defaults to find subsequent ones.

For example, when ServiceEnvelopeClass.ClassCluster ~ prod (not dev) is selected
for a function which performs remote login,
it makes sense to set ServiceArgType.AccessType ~ ro as default.
Conversely, if it is ~ dev (not prod), ServiceArgType.AccessType should be assumed as rw by default.

Such defaults cannot be adquately assigned statically because it depends on the function (plugin logic),
knowledge what will be done with these data_envelope-s, and should be extensible (again, by plugins).

The idea is to add a server-side hook for InvocatorPlugin
which inspects currently selected data_envelope-s
and computes these defaults for the next data_envelope-s.

There should be a way to make different registered commands request different servers via different local configs.

See FS_57_36_37_48.multiple_config_coexistence.md for details.

At the moment, argrelay server uses single Mongo DB collection for all objects.

Server:

• cleans this single collection completely and populates all data_envelope-s on start,
• keeps using that single collection for all searches while alive.

It works fine for small data sets, but adds extra latency (observable with mongomock) for large ones.

The idea is to specify extra parameter indicating collection name while storing and querying data_envelopes:

• Server will inspect this parameter to select which collection it is supposed to be stored in.
• Selected function will provide information in search_control which collection specific data_envelop has to be searched in.

This will:

• Reduce latency in only specific scenarios.

  This may be simingly non-serious use cases with mongomock instead of real Mongo DB.
  But mongomock is expected to be the default choice (majority of installations).

• Enable us to setup different handling for different collections.

  Some of them might be too big to re-populate on re-start (too long).

• Avoid MongoDB limits on number of indexes per collection.

Some objects (for example, hosts or services) can exists in multiple places of descrete space at the same time.

For example, host can be both dev and test at the same time.

Most common use case are tags/labels (of any domain-specific meaning)

where more then one tag or label can be assigned to an object.

For example, an object being tagged by "red" and "blue" at the same time, should be found by "red" or "blue".

Is there another approach?

A naive alternative is to create copies of objects in every required "descrete space coordinate" where we want to find it.

However, user will have to disambiguate these copies by explicitly providing "red" or "blue" arg on the command line.
If one object is used for both, this is not required as the search stops when single object is found.

See also

See FS_06_99_43_60.list_arg_value.md.

See: FS_61_67_08_53.

At the moment, the server config exposes too much of unnecessary internal details (not obvious to user).

Rethink it via FS_33_76_82_84.global_tree.md.

At the moment, argrelay is HMI-focused (implying that Human inputs the command):

• Arguments can be reordered (and argrelay will guess which property/type they are based on value).
• Fewer arguments is among main features (if object can be identified with fewer, no other args are required).
• ... other tricks.

However, this might be unreliable for scripting as scripts run without human in the control loop.

Scripts will break if new data contains overlapped value sets across properties/types or if more args needed to identify objects required (even if data does not change, but some of the arguments do, there are "places in coordinate space" which are uniquely identified with fewer args and other places where same number of args is not enough).

"Strict script" mode should address these issues.

See derived classes of BaseResponse.

Combine InvocationInput and InterpResult into one as they are similar.

Make all data_envelope-s be exchanged as part of envelope_container-s.

Make EnvelopeContainer.data_envelope a list of data_envelope-s and send them wrapped into EnvelopeContainer per search_control class. This will make EnvelopeContainer.data_envelopes (potentially) contain more than one data_envelope. But this unifies code, makes tests less different, and actually wraps data_envelope-s into metadata of EnvelopeContainer.

See: FS_74_69_61_79.

Although not the primary purpose, basic web GUI with async queries can show what argrelay CLI tries to do in its more constraint terminal environment.

It also allows demoing argrelay for remote users (who don't have immediate access to shell).

When command line is executed (and plugin receives InvocationInput data) those data_envelope-s as dict-s do not contain top-level keys which are clearly populated on the server side. See sample dict here - these keys (SomeTypeA, ...) would be missing.

• Server-side data contains them - see RelayLineArgsServerRequestHandler.py
• Client-side data has none - see RelayLineArgsClientResponseHandler.py

There should be a way to add custom data and custom commands via configuration only.

This will let user use immediate customization with small number data entries (maintain-able manually).

See FS_49_96_50_77.config_only_plugins.md.

Currently, there is large space of values what Bash can provide to the client (RunMode enum and CompType)
while actual space of values (their combinations) sent to the server is limited.

This:

• creates confusion,
• leaks meaningless data to the server,
• complicates server logic.

Map Bash input on the client and send specific values to the server.