Deprecating the 'in process kernel' machinery?

--001a114023a621d7c60551c16ec0
Content-Type: text/plain; charset="UTF-8"

When we first introduced the Qt console, thinking about the kernel/frontend
separation mostly as a way to provide multiple frontends for the Python
kernel, we wrote some machinery to run a kernel 'in process', without the
ZMQ sockets.

Since then, the most popular frontends are Javascript-based, and we've
discovered the value of the protocol in supporting kernels for languages
other than Python. The in-process kernel machinery has become a
poorly-maintained, little-used corner of the code, eliciting a silent groan
whenever I see an issue asking about it. It's de-facto deprecated already,
and I'd like to make this official, so we can eventually get rid of that
code entirely.

There's one major use case I've seen for the IPK machinery: people writing
PyQt GUI applications who want to embed the Qt console and use it to
interactively manipulate objects in the same process. This is definitely a
valid and interesting thing to do, so what can we suggest as an alternative
to IPK?

A: Embed the kernel in the application and run the Qt console as a separate
window. I think we have examples of this around somewhere, though I forget
where.
B: Make the Qt application (with embedded console) manipulate the objects
of interest in a separate process, which also runs the kernel machinery.
This may have some other advantages to the application, but it's a lot of
work and clearly not suitable for every case.
C: Embed both console and kernel in the same application, but still using
ZMQ sockets so that they can use more of the standard communication
machinery. We have the machinery to integrate the kernel with the Qt event
loop, so this should be possible; is anyone aware of any examples of code
doing this?

Thanks,
Thomas

-- 
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
To post to this group, send email to jupyter-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAOvn4qjS2tvCfh9wAsBq7DFL1AJ9c7t7RFq8U06Wa51cXAmZVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--001a114023a621d7c60551c16ec0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div>When we first introduce=
d the Qt console, thinking about the kernel/frontend separation mostly as a=
 way to provide multiple frontends for the Python kernel, we wrote some mac=
hinery to run a kernel &#39;in process&#39;, without the ZMQ sockets.<br><b=
r></div>Since then, the most popular frontends are Javascript-based, and we=
&#39;ve discovered the value of the protocol in supporting kernels for lang=
uages other than Python. The in-process kernel machinery has become a poorl=
y-maintained, little-used corner of the code, eliciting a silent groan when=
ever I see an issue asking about it. It&#39;s de-facto deprecated already, =
and I&#39;d like to make this official, so we can eventually get rid of tha=
t code entirely.<br><br></div>There&#39;s one major use case I&#39;ve seen =
for the IPK machinery: people writing PyQt GUI applications who want to emb=
ed the Qt console and use it to interactively manipulate objects in the sam=
e process. This is definitely a valid and interesting thing to do, so what =
can we suggest as an alternative to IPK?<br><br></div>A: Embed the kernel i=
n the application and run the Qt console as a separate window. I think we h=
ave examples of this around somewhere, though I forget where.<br></div>B: M=
ake the Qt application (with embedded console) manipulate the objects of in=
terest in a separate process, which also runs the kernel machinery. This ma=
y have some other advantages to the application, but it&#39;s a lot of work=
 and clearly not suitable for every case.<br></div>C: Embed both console an=
d kernel in the same application, but still using ZMQ sockets so that they =
can use more of the standard communication machinery. We have the machinery=
 to integrate the kernel with the Qt event loop, so this should be possible=
; is anyone aware of any examples of code doing this?<br><br></div>Thanks,<=
br></div>Thomas<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Project Jupyter&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:jupyter+unsubscribe-/[email protected]">jupyter+uns=
ubscribe-/[email protected]</a>.<br />
To post to this group, send email to <a href=3D"mailto:jupyter@googlegroups=
.com">jupyter-/[email protected]</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/jupyter/CAOvn4qjS2tvCfh9wAsBq7DFL1AJ9c7t7RFq8U06Wa51cXAmZVg%40ma=
il.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/d/msgid/jupyter/CAOvn4qjS2tvCfh9wAsBq7DFL1AJ9c7t7RFq8U06Wa51cXAmZVg%40m=
ail.gmail.com</a>.<br />
For more options, visit <a href=3D"https://groups.google.com/d/optout">http=
s://groups.google.com/d/optout</a>.<br />

--001a114023a621d7c60551c16ec0--