Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some roadmapping #10

Merged
merged 3 commits into from
Dec 22, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions MESSAGING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
The following is a rough outline how messaging could work between the Tauri Rust backend, the frontend webview, and the kernel runtime.

## Execution messaging

Within this example we're going to assume the kernel is already alive and nothing else is queued or busy.

![Messaging](https://private-user-images.githubusercontent.com/836375/292332142-d5470afc-0962-4a19-94e5-06967cc5c982.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTEiLCJleHAiOjE3MDMyMDAwNjcsIm5iZiI6MTcwMzE5OTc2NywicGF0aCI6Ii84MzYzNzUvMjkyMzMyMTQyLWQ1NDcwYWZjLTA5NjItNGExOS05NGU1LTA2OTY3Y2M1Yzk4Mi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBSVdOSllBWDRDU1ZFSDUzQSUyRjIwMjMxMjIxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDIzMTIyMVQyMzAyNDdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT04MjdiOWE4NDhmZWZkZTNhZWE2YzdlZjY1ZDlkZTM1YzlkNjEyZmE3ZWI5NjYwZTQwZjUwY2M4ZmEwYzU0YzE0JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.9t2XuuaMrUagjRTMQ4RlkdKccMt03wf9DxKCckIf1B8)


1. The Notebook Frontend `invoke`s `execute_cell` by ID.
2. The Tauri Core Backend receives this message, uniquely determines which notebook to work with, and dispatches to the notebook service.
3. The Notebook service creates an `execute_request` which starts running the cell. The , indicated by "Cell running," and sends a confirmation response back to the Tauri Core Backend.
4. The Tauri Core Backend sends a Tauri IPC Response back to the Notebook Frontend as a confirmation.
5. As the cell executes and produces output, the Notebook Backend sends events about the state of the notebook application include cell state (queued, busy, etc.) as well as output back to the Tauri Core Backend.
6. The Tauri Core Backend forwards these events to the Notebook Frontend.
7. Once the cell execution is finished, the Notebook Backend sends a "Cell finished" event to the Tauri Core Backend, which then sends an event to the Notebook Frontend to update the cell state.
27 changes: 27 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,33 @@ nteract next is a desktop application for notebooks built on:
* Tauri
* Tokio


```
+-------------------+ +-------------------+
| Tauri Main Process| | Kernel Sidecar |
+-------------------+ +-------------------+
| ^
| IPC and Events |
v v
+-------------------+ +-------------------+
| State Update | | Jupyter Message |
| Handler | | Handlers |
+-------------------+ +-------------------+
| ^
| Events |
v v
+-------------------+ +-------------------+
| Event Bus |<--->| Notebook Document |
+-------------------+ | Service |
| |
| Events |
v v
+-------------------+ +-------------------+
| Web View of | | In-Memory State |
| Document | | of Document |
+-------------------+ +-------------------+
```

## Development

Clone the repo, cd into `nteract-next`
Expand Down
76 changes: 76 additions & 0 deletions ROADMAP.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
Project Overview
----------------

**Objective**: Develop nteract v2 as a performant and stable desktop notebook application, focusing on fluid user experience and rapid prototyping.

### Key Features

* **Fluid User Experience**: Emphasis on speed and responsiveness, particularly in creating and manipulating notebook cells.
* **Backend-Managed State**: State management primarily handled by the Rust backend.
* **Performance Focus**: Leverage Tauri's performance benefits to enhance application efficiency.

Lessons from nteract v1
-----------------------

* Transition away from nteract web, content refs, myths, and bundled components.
* Adopt a one notebook per window approach.

Strategy for nteract v2
-----------------------

* Build an integrated application, not a modular toolkit.
* Offload outputs to a content store for standardization and performance.
* Emphasize a design that facilitates fluid interactions and rapid prototyping.
* Switch to Tailwind CSS and/or shadcn/ui for UI development.

Technical Decision: Tauri vs. Electron
--------------------------------------

* Preference for Tauri due to its performance benefits and alignment with the project's renewed focus, despite Electron's familiarity and more complete API set.

Phases of Development
---------------------

### Initial Phase: Planning and Research

👇🏻 You are here 👇🏾

* Define the project scope and technical requirements.
* Research Tauri's capabilities
* Investigate integration with Jupyter kernels.
* Draft a detailed design document outlining the desired user experience.

#### Integration and Testing

* Continuous integration of separate backend and frontend components
* Develop end-to-end tests using a real kernel

#### Deployment and Documentation

* Ongoing preparation for frequent releases with a focus on CI/CD efficiency
* Continuous development of documentation and user guides
* Foster community involvement and establish contribution guidelines

### Phase I: Prototype

#### Backend Development (Rust)

* Implement functions for notebook manipulation and interaction with Jupyter kernels.
* Establish communication protocols with the frontend.
* Create a notebook backend to keep track of the ongoing document, a running kernel, and establish handlers for document changes

#### Frontend Development

* Design and implement the notebook viewing and editing interface using Tailwind CSS.
* Focus on creating a immersively iterable notebook for prototyping
* Rely on the backend to have the source of truth for the notebook state as well as kernel state, only looking to the frontend as the view layer

### Phase II: CRDT

* Integrate CRDT logic for real-time editing and synchronization with the backend.

Risk Management
---------------

* Address challenges in adopting new technology (Tauri) and integrating it with existing systems.
* Ensure a balance between performance focus and maintaining an intuitive and engaging user interface.