Capytale discussion

[SylvainCorlay]

• [ ] OCaml kernel for JupyterLite
• [ ] input() synchronous function support
• [ ] Activityjs support (lab extensions)
• [ ] Matplotlib backend support of Basthon (FigureCanvasWasm)
• [ ] p5: non-webworker Basthon jupyterlite kernel - exploration of alternatives in the case of webworker Basthon kernel
• [ ] Collaborative editing (re-discuss later).
• [ ] Debugger: discuss future development of a DAP in JupyterLite / Look into Thonny's user experience.

@casatir

[jtpio]

References:

• https://codimd.apps.education.fr/5-EvMdHGRrCzt61oRqD-Og#

[tjaisson]

@jtpio @SylvainCorlay @casatir @nicolaspoulain @chardetm

Bonjour Jérémy,

Capytale intègre déjà des outils en iframe mais nous avons utilisé à chaque fois une librairie RPC en surcouche au postMessage natif pour la communication distante.
Cela simplifie les échanges en apportant un fonctionnement bidirectionnel : l'appel d'une fonction distante permet de passer des paramètres mais aussi d'obtenir une valeur de retour.
Nous avons utilisé @mixer/postmessage-rpc (lic. MIT) mais j'ai récemment découvert comlink (lic. Apache 2.0) qui me semble meilleure. Il y en a peut-être d'autres.

Concernant les échanges qui ont lieu via RPC, nous n'avons malheureusement pas fait deux fois la même chose. J'ai décidé de "normaliser" un peu en définissant en typescript les interfaces exposées des deux côtés. C'est publié sur github @capytale/metaplayer-rpc. C'est l'endroit pour se mettre d'accord ! Nous y ajouterons les interfaces définies avec tous nos partenaires.
Ce n'est pas finalisé mais tu peux peut-être déjà y jeter un œil pour voir si le principe te convient.

J'ai l'intention d'y écrire un "agent capytale" que l'outil intégré pourrait utiliser comme un paquet ou comme un .js servi sur notre CDN. Le but est de découpler le code côté outil vis à vis de la librairie RPC utilisée.

[tjaisson]

@jtpio @SylvainCorlay @casatir @nicolaspoulain @chardetm

J'ai publié le paquet @capytale.fr/metaplayer-rpc. Il permet à l'iframe d'obtenir un socket pour :

• brancher l'implémentation de son interface
• consommer l'interface de l'hôte

Il apporte aussi le typage des interfaces.

J'ai ajouté la dépendance et modifié un peu ton code (branche rpc) mais je n'ai pas trouvé comment adapter la page hôte de ta démo car elle n'a pas de build.

J'ai donc modifié la démo metaplayer de @capytale.fr/metaplayer-rpc sur une branche draft pour y mettre l'url localhost de ton iframe.

Je n'ai que deux boutons :

• l'un récupère le contenu. Je le garde en local.
• on peut modifier le notebook...
• l'autre bouton remet l'état récupéré précédemment.

[jtpio]

Super, merci @tjaisson pour les nouvelles et les avancées dans ces repos !

J'ai ajouté la dépendance et modifié un peu ton code (branche rpc) mais je n'ai pas trouvé comment adapter la page hôte de ta démo car elle n'a pas de build.

Oui effectivement il n'y a pas de build car c'est juste une page HTML avec très peu de JavaScript, pour servir de demo.

Peut-être que l'on peut simplement importer @capytale.fr/metaplayer-rpc depuis un CDN via un script tag ? Par exemple depuis jsdelivr.

Sinon on peut aussi ajouter une étape de build si cela permet de simplifier l’intégration.

[jtpio]

Nous avons utilisé @mixer/postmessage-rpc (lic. MIT) mais j'ai récemment découvert comlink (lic. Apache 2.0) qui me semble meilleure. Il y en a peut-être d'autres.

Pour info, il semblerait que le repo qui correspond à @mixer/postmessage-rpc soit archivé:

Aussi JupyterLite utilise comlink pour faire passer les messages entre l'application et les kernels, donc on pourrait effectivement partir la-dessus.

[jtpio]

@tjaisson @casatir @nicolaspoulain @chardetm

Pour faire suite au dernier meeting, serait-il possible de poster ici (ou dans une autre issue) la liste des fonctionnalités que l'interface Notebook 7 doit fournir via l'interface des contrats ?

Cela me permettrait de commencer a regarder de mon cote, afin de vous faciliter l’intégration.