EvaNotebook

Introduction

EvaNotebook is a computational notebook specifically designed to operate solely within a browser environment, without the need for a client-server architecture. Its design lends itself to the development of prototypes, experimental processes, and system scenarios with a main emphasis on multilingual programming for event-driven architectures. It achieves this with the assistance of a decentralized database and incorporates various application protocols, including WebRTC, WebSockets, and MQTT, providing a higher level of abstraction.

Given those pain points and needs, we provide the following addressing:

Setup

In accordance with the philosophy described earlier, we have implemented mechanisms to receive and cleanse data from multiple distributed real-time sources locally with programs written in JavaScript, Python (specifically, Pyodide), SWI-Prolog, SQL, and others in cooperation. To achieve this, we utilize transparent web workers that effectively manage the Origin Private File System (OPFS) and our decentralized IndexDB version. These mechanisms are integrated with MQTT, WebRTC, WebSocket, and HTTP APIs, drawing inspiration from the concepts put forth by ReactiveX and its RxJS implementation.

Explore and Analyze

Our notebook doesn't inherently feature a self-stabilization algorithm. If your browser crashes, you will have to restart your work.

Manage code

On one hand, the browser environment offers a plethora of developer tools, especially in chromium-based browsers, that greatly enhance the software engineering experience. These tools include powerful debugging capabilities, network analysis tools, and the ability to extend the functionality of the browser through extensions.

On the other hand, working within the browser environment also introduces certain challenges that need to be addressed. Security constraints and browser bugs can pose obstacles to smooth development. For example, the Cross-Origin Resource Sharing (CORS) restriction can limit the ability to make requests to resources from different origins.

Reliability

If your computer has the capacity to handle large datasets, you certainly may load them. However, it's important to note that our primary focus is not on batch analysis, but rather on online analysis. In fact, the browser environment might not always be the most suitable for training machine learning models. We would like to caution you that browsers are prone to unexpected crashes when certain limits are reached.

Archival

Although we preserve history through the revision mechanism provided by RxDB, we do not yet offer an easy way to recover past versions.

Security

Even though our notebook operates in a browser, it primarily functions as local-offline software by default, as detailed in \cite{10.1145/3359591.3359737}. Users maintain full ownership of their data, and we don't store anything on the cloud.

Share and Collaborate

Our notebook supports the publishing of results in the form of demos or reports, enables collaborative editing, and provides real-time shared memory functionality through P2P replication and HTTP schemes. Conflict resolution is achieved using CRDT and Lamport Clocks. Additionally, we have chosen RxDB as our database management system, utilizing IndexDB as the underlying storage, which is a reactive database specifically designed to work on browsers and draws inspiration from the multi-master replication approach of CouchDB. Our replication model follows a basically available, soft state, eventually consistent approach, as described in \cite{pritchett2008base}, which contrasts with the ACID model.

Broadcast
CRDT
Leader Election
RPC and Middleware

TODO: Favela's work on collaborative software.

Reproduce and reuse

As developers, data scientists, and researchers, we understand the frustration caused by Dependency Hell. To address this issue, our notebook maintains a stable list of libraries that are readily available for use. However, it's important to note that we cannot guarantee that every library in npm and pip will work on a browser environment.

Notebooks as Products

Today, most end-users expect software to work in ready-to-use environments such as web browsers or smartphone apps. Deploying to a browser is generally easier compared to the smartphone ecosystem, making it the preferable choice. Our notebook supports a publication mode where you can deploy without visible code and have read-only access. Furthermore, if you are interested in running a background service, a browser can operate in headless mode, which eliminates the need for a graphical user interface to execute a notebook.

% $Explain \ref{fig:dataflow} Topological Sort, Consensous, Leader Election, Distributed Search, CRDT, Self-stabilization, reactivity y=f(x1,x2,x3,...) where xi are signals, descentralizad filesystem with Kandemelia$

% As EvaNotebook employs reactive programming, it provides simplified APIs for MQTT, WebRTC, and WebSocket protocols, based particularly on the ideas from ReactiveX and its RxJS implementation. \\
% What is type of reactivity of RxJS?

% Dependency hell
% Glitch
%
https://queue.acm.org/detail.cfm?id=1394128 P2P with RXDB, PeerJS and WebRTC P2P, collaboration and shared state lamport clocks
% Designing Data Intensive Applications
%
https://stackoverflow.com/questions/35646413/is-reactivex-considered-reactive-programming
%
https://dl.acm.org/doi/pdf/10.1145/349299.349331
%
https://dl.acm.org/doi/abs/10.1145/349299.349331
% %
https://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming/1030631#1030631
%
https://sci-hub.se/https://dl.acm.org/doi/abs/10.1145/2501654.2501666
%
https://sci-hub.se/https://dl.acm.org/doi/10.1145/2048066.2048100
%
https://sci-hub.se/https://dl.acm.org/doi/abs/10.1145/2499370.2462161
%
https://dl.acm.org/doi/abs/10.1145/2501654.2501666
%
https://dl.acm.org/doi/abs/10.1145/2499370.2462161
%
https://www.inkandswitch.com
% %
https://www.inkandswitch.com/pixelpusher/#introducing-pixelpusher
%
https://www.inkandswitch.com/pushpin/
%
https://www.inkandswitch.com/local-first/
%
https://dl.acm.org/doi/abs/10.1145/3313831.3376729
%
https://dl.acm.org/doi/abs/10.1145/3173574.3173606
%
https://repository.brynmawr.edu/compsci\\_pubs/54/
%
https://dl.acm.org/doi/abs/10.1145/3359141

hattopadhyay, S., Prasad, I., Henley, A.Z., Sarma, A., Barik, T.: What’s wrong
with computational notebooks? pain points, needs, and design opportunities.