Support all message types in jlkernel

[stevengj]

Currently, we only (barely) support execute_request and the corresponding replies. We need to support all of the IPython message types:

• execute_request and execute_reply (incomplete, see fix handling in jlkernel execute_request #5)
• pyout
• getattr_request and getattr_reply / setattr_request and setattr_reply (these may not actually be part of the spec as per @minrk's comment below)
• object_info_request and object_info_reply
• complete_request and complete_reply
• history_request and history_reply (needed in qtconsole front-end). Stub implementation (commit f1da940) pending clarification in Julia language interoperability (meta-issue) ipython/ipython#3806.
• connect_request and connect_reply
• kernel_info_request and kernel_info_reply
• shutdown_request and shutdown_reply
• stream (need stdout/stderr redirection from Julia #3823)
• display_data (depends on need standardized display function for non-text data (e.g. arbitrary MIME types) julia#3817)
• data_pub
• pyin
• pyerr (may require protocol updates with IPython folks)
• status
• crash (not actually in the spec, see below)
• input_request / input_reply (stdin redirection) redirect stdin to frontends #42

[stevengj]

commit 4d06e66 adds a crash message when we catch an unexpected exception, but IPython doesn't seem to respond to it. I must be doing something wrong. @fperez?

[minrk]

Unrecognized message types generally do not have any effect in frontends. If anything, they typically just produce a warning.

[stevengj]

@minrk, I'm confused: IPython's front ends don't recognize the (documented) crash message?

[minrk]

Arg! No - there are a couple of message types in the spec that belong in the 'unimplemented future ideas' section. Those are get/setattr and crash. I will make sure that my wire-protocol doc PR fully updates the message spec doc to reflect reality.

[stevengj]

Basically done except for #42 and #47, so I'm closing this meta-issue.