remi icon indicating copy to clipboard operation
remi copied to clipboard

compatibility with pyscript

Open stonebig opened this issue 3 years ago • 11 comments

this is a naive question: would remi work in pyscript/pyodide environment ?

stonebig avatar May 28 '22 21:05 stonebig

@stonebig Interesting question, I never tried. However I doubt that pydiode can host a webserver in browser.

dddomodossola avatar May 28 '22 22:05 dddomodossola

@dddomodossola I'm looking for the same answer!

No the webserver never will work on the browser

But, we can move the whole frontend to pyscript, but a different approach will be needed, like a remote DOM.

Another point is that the application can be isolated to work only on the browser, replacing access to local resources!

The advantage of pyscript, right now, is that it can replace the javascript in Remi by python code!

MaxMorais avatar May 28 '22 22:05 MaxMorais

@MaxMorais however the pydiode website mentions that it supports all the standard python library. So maybe sockets are supported?

dddomodossola avatar May 29 '22 05:05 dddomodossola

@dddomodossola I'll try this on my side, to verify that hipotesis!

MaxMorais avatar Jun 04 '22 17:06 MaxMorais

@MaxMorais ;-)

dddomodossola avatar Jun 05 '22 07:06 dddomodossola

@dddomodossola

After some digging I found this

https://docs.pyscript.net/latest/reference/faq.html#why-dont-requests-and-black-work Frequently asked questions — PyScript documentation

So, no comptibility to run a socket server on the browser

But, it still a valid choice, since we will continue comunicating via WebSockets!

I still thinking Remote DOM is the right approach!

MaxMorais avatar Jun 30 '22 23:06 MaxMorais

Hello @MaxMorais ,

Thank you for the information. Why you say that Remote DOM is the right approach? I see an over complication, an additional step and an additional library in the middle.

dddomodossola avatar Jul 01 '22 06:07 dddomodossola

@dddomodossola sorry, our conversation get lost on the follow of my emails!

The Remote DOM, allow us, to control and transfer states, between the backend and the frontend, without interchange code.

I'll try ilustrate this with a code snippet:

from remote import document, queue

el = document.createElement("div")
el.setAttribute("x-display", "box")

print(queue.queue)

This will produce a JSON like that

[
  ["createElement", ["element_div_140464070463344", "DIV"], null], 
  ["setAttribute", ["element_div_140464070463344", "display", "box"], null]
]

On this approach what I'm transfering is just a JSON between the backend and frontend, but preserving the state in both sides.

I'm sharing the implementation I do have in an application https://gist.github.com/MaxMorais/4711355b95073e908365652295bdddae

I'm using this piece of software on a system, that needs a desktop and a webUI.

Since the desktop UI is made in GTK, this thin layer, was the unique option, I have found, to create a compatibility layer on the web.

On the webside, ofcourse, I had to implement webcomponents for every single GTK component, but, I do have used the same library to implement the components.

There's no transfer of JavaScript, but, I'm able to control, acquire and modify the values of every variable in JavaScript, using Proxies and Observability.

MaxMorais avatar Oct 14 '22 18:10 MaxMorais

The virtual server ( just a mock of BaseHTTPRequestHandler ) approach servicing html blob objects to an iframe is probably simpler to implement for remi particular case.

pmp-p avatar Mar 27 '23 16:03 pmp-p