Backporting events to v1

[dlqqq]

cc @Zsailer @blink1073 @ellisonbg @3coins

Context and motivation

As you might know, Piyush is working on a server extension for notebook scheduling: #957. Right now, the extension maintains a mapping between file path <=> scheduled notebook jobs in a SQLite table. However, an obvious shortcoming of this approach is that if a user renames a file, the associated notebook jobs are lost entirely.

I discussed this with Brian and Piyush very early on in the development process, and this was actually the primary motivation behind the File ID service I have been building for the past month. The idea is for Piyush's notebook scheduling extension to call my File ID extension to retrieve a file ID for each path. In short:

• When creating a notebook job, we first call index() on a file to create a file ID for that path (and do nothing if a file ID already exists)
• When returning a list of associated notebook jobs on a file, we call get_id() to retrieve the file ID associated with that file. Then we use that file ID to look up the notebook jobs associated with it in a SQLite table.

However, because Piyush's server extension must support Jupyter Server v1 to be available to existing users as soon as possible, and because it will eventually depend on my File ID extension, then naturally this would require us to backport Jupyter Events to v1 as well.

Issue

I created this issue mainly to ask three questions:

1. Are there any objections to backporting Jupyter Events?
2. Can we decide on a target date on backporting Jupyter Events?
3. Are there any outstanding issues that must be resolved in Jupyter Events or in Jupyter Server before we backport it to v1? (e.g. performance concerns, better error handling, etc.)

This issue is also intended to track the remaining work needed for this backport. I will add a checkbox list as this discussion evolves.

[ellisonbg]

Thanks David. I want to clarify that while the file id service is needed for the notebook job experience to work robustly, there are a number of other places it is needed including commenting and real-time collaboration.

[Zsailer]

Yeah, thanks David!

I don't have any objections to backporting to v1. I believe all of the changes are additive—assuming there is no major performance concerns. (I fixed the small issue with emitting when no listeners are listening).

I'm a little low on bandwidth this month, so I'm not sure I'll have much time to do the backporting. Would you be interesting in taking this on? I can focus on measuring the performance of jupyter_events.

I believe we can get this released pretty quickly after the backport PR lands. I'm happy to review any incoming PRs quickly to keep things moving. Just let me know what you think.

[dlqqq]

@Zsailer Hey, Piyush and I discussed this more in detail after the last server call, where Piyush proposed adding support for Jupyter Server v2 into JupyterLab 3.x. This solution would actually meet our use-case (having notebook scheduling + file ID available in latest stable JL), and meet other lower-priority goals such as RTC and commenting for JL 3.x.

People can feel free to re-open this issue if they discover any other use-cases for having support for event bus in JL installations <=3.4.