I know the justification of CLI http, but I'm not sure there's any justification for job communications over HTTP (even though it can easily be done).. do I or don't I add an option to platforms:

            Conf('communication method',
                 VDR.V_STRING, 'zmq',
                 options=[meth.value for meth in CommsMeth], desc=f'''
                The means by which task progress messages are reported back to
                the running workflow.

                Options:

                zmq
                   Direct client-server TCP communication via network ports
                poll
                   The workflow polls for task status (no task messaging)
                ssh
                   Use non-interactive ssh for task communications

                .. versionchanged:: 8.0.0

                   {REPLACES}``global.rc[hosts][<host>]task communication
                   method``.
            ''')

oliver sanders:

In practice sites would want to set [platforms][localhost]communications method to match [CLI]communications method so I don't think there is any benefit to separating the two.

How does comms method poll make sense for cylc broadcast?

If I use the same [platforms][localhost]communications method should I keep a set of poll applicable tasks to check this against then default to zmq if not applicable?

oliver sanders:

In practice sites would want to set [platforms][localhost]communications method to match [CLI]communications method so I don't think there is any benefit to separating the two.

How does comms method poll make sense for cylc broadcast?

If I use the same [platforms][localhost]communications method should I keep a set of poll applicable commands to check this against then default to zmq if not applicable?

Also why just localhost I assume people will be able to define remote platforms with https as the comms method?.. (which, I assume, will be carried over by CYLC_TASK_COMMS_METHOD in the job environment)..

localhost is only really use in any interactive scenario, I suppose, so that's what I'd lookup in the global conf

Guess I answered my own question 😅

Also why just localhost I assume people will be able to define remote platforms with https as the comms method?.. (which, I assume, will be carried over by CYLC_TASK_COMMS_METHOD in the job environment)..

localhost is only really use in any interactive scenario, I suppose, so that's what I'd lookup in the global conf (in the absence of CYLC_TASK_COMMS_METHOD)

Guess I answered my own question 😅

Also why just localhost I assume people will be able to define remote platforms with https as the comms method?.. (which, I assume, will be carried over by CYLC_TASK_COMMS_METHOD in the job environment)..

localhost is only really used in any interactive scenario, I suppose, so that's what I'd lookup in the global conf (in the absence of CYLC_TASK_COMMS_METHOD)

Guess I answered my own question 😅

In reply to @dwsutherland:matrix.org

oliver sanders:

In practice sites would want to set [platforms][localhost]communications method to match [CLI]communications method so I don't think there is any benefit to separating the two.

How does comms method poll make sense for cylc broadcast?

If I use the same [platforms][localhost]communications method should I keep a set of poll applicable commands to check this against then default to zmq if not applicable?

In reply to @dwsutherland:matrix.org

Also why just localhost I assume people will be able to define remote platforms with https as the comms method?.. (which, I assume, will be carried over by CYLC_TASK_COMMS_METHOD in the job environment)..

localhost is only really used in any interactive scenario, I suppose, so that's what I'd lookup in the global conf (in the absence of CYLC_TASK_COMMS_METHOD)

Guess I answered my own question 😅

In reply to @oliver-sanders2:matrix.org
(we can't set communications method at the workflow level in Cylc 8)