# Jupyter Server Weekly Meeting
- Where: [`jovyan` Zoom](https://zoom.us/my/jovyan?pwd=c0JZTHlNdS9Sek9vdzR3aTJ4SzFTQT09) (pwd: c0JZTHlNdS9Sek9vdzR3aTJ4SzFTQT09)
- Historical notes can be found [here](https://github.com/jupyter-server/team-compass/issues/4).
## September 9th, 2021
| Name | affiliation | username |
| ------------- | --------------------------- | -----------------|
| Zach Sailer | Apple | @Zsailer |
| Luciano Resende | IBM | @lresende |
| Thi Nguyen | Startup | @duongnt |
| David Brochart | QuantStack | @davidbrochart |
| Karla Spuldaro | IBM | @karlaspuldaro |
| Adrien Delsalle | QuantStack | @adriendelsalle |
| Kevin Bates | IBM | @kevin-bates |
| Steven Silvester | Apple | @blink1073 |
| A. T. Darian | Two Sigma | @afshin |
### Agenda + Minutes
- New Release: [v1.11.0](https://github.com/jupyter-server/jupyter_server/releases/tag/v1.11.0) (thanks, Steve!)
- Proposal: Towards a new generic and composable server
- Should the following repos move into the Jupyter Server organization?
- If so, we'll need to have clear messaging that says these projects are experimental.
- We're not abandoning the current Jupyter Server :smile:
- We'll vote on this next week.
- Technology stack overview:
- Pydantic and Typer:
- Embrace Python's native type hints/annotation.
- Together, they remove most of the need for Traitlets
- Handles most data validation automatically, and offers a simple way to define custom types.
- Typer offers a simple API for adding command-line interfaces to applications for configuring Python objects.
- Can we drop traitlets? What's left in Traitlets?
- “Observe” other traits. Necessary for ipywidgets.
- loading configuration from file.
- Comparatively, this is a small amount of code to maintain.
- We can likely contribute these things upstream too.
- Built on top of Pydantic.
- Native syntax for type annotations/hints
- Auto generate (developer) documentation and unit-tests (via hypothesis) for free.
- [ASGI](https://asgi.readthedocs.io/en/latest/) implementation, i.e. async by default.
- Provides a significantly more robust mechanism for discovering and loading application extensions.
- As many people have experienced, today’s Jupyter Server's extension discovery/loading is quite brittle.
- Does this change the kernel messagine spec? Will this invalidate current kernels?
- Will server extensions have to migrate?
- Is it possible to somehow prevent or minimize this in the future?
- Today's server extension API isn't (and was never) clearly specified. Pluggy defines a clear specification for plugin systems. It's more stable and less likely to change in the future.
- Will this change the current REST API?
- It's not a immediately clear. Right now, no. But it's possible things might need to change in the future, and require a JEP.
- Does this need to wait for classic Notebook to retire?
- This is an issue to be addressed by the new software steering council. Yes, this should coincide the the retirement of the classic notebook server.