rawpython / remi

Python REMote Interface library. Platform independent. In about 100 Kbytes, perfect for your diet.
Apache License 2.0
3.48k stars 401 forks source link

compatibility with pyscript #492

Open stonebig opened 2 years ago

stonebig commented 2 years ago

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

dddomodossola commented 2 years ago

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

MaxMorais commented 2 years ago

@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!

dddomodossola commented 2 years ago

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

MaxMorais commented 2 years ago

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

dddomodossola commented 2 years ago

@MaxMorais ;-)

MaxMorais commented 2 years ago

@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!

dddomodossola commented 2 years ago

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.

MaxMorais commented 1 year ago

@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.

pmp-p commented 1 year ago

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.