Adding comm_info_request and comm_info_reply messages

[SylvainCorlay]

Adding a comm_list_[request/reply] shell message. This requires jupyter/jupyter_client#34.

[minrk]

This will presumably need to be cast to a list.

[SylvainCorlay]

that's right. Python 3 sorry.

[SylvainCorlay]

Done

[jasongrout]

ipykernel? Actually, we should just answer the question now...

[SylvainCorlay]

I think that it is @minrk's call.

[minrk]

I think this is a fine place for it.

[SylvainCorlay]

Rebased to use the new schema for the comm_info_reply.

Message type: ``comm_info_request``::

    content = {
        #optional, (filter by target name)
        'target_name' : str,
    }

Message type: ``comm_info_reply``::

    content = {
        # A dictionary of the comms, indexed by uuids.
        'comms': {
            comm_id: {
                'target_name': str,
            },
        },
    }

[SylvainCorlay]

I added the ability to filter by target name as discussed earlier.

[minrk]

thanks, @SylvainCorlay!

[SylvainCorlay]

I hesitated to give a list of target names rather than a single target name for the filter, but it would have been the only message having a list of target names, so it is probably more consistent with the rest of the messages to only allow one.

[minrk]

@SylvainCorlay good choice. I don't imagine the use case for people wanting more than one but less than all is worth having the extra logic.

[minrk]

Can you add a if not hasattr(KC, 'comm_info'): raise SkipTest()? Then this test will run while comm_info is defined, but skip while jupyter_client is < 4.1.

[SylvainCorlay]

Done!

[SylvainCorlay]

(Done)

[minrk]

@SylvainCorlay thanks! Now I think we can start getting this tested for those living on master.