-
Notifications
You must be signed in to change notification settings - Fork 61
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
Python server demo #272
Python server demo #272
Conversation
✅ Deploy Preview for dicomweb ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for volview ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
c4277ff
to
69940b0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing, succinct, magic!
69940b0
to
2a39f2f
Compare
@aylward I've updated the demo with a streaming progress example. |
✅ Deploy Preview for volview-dev ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
The python server has been updated and improved. Check out the
General VolView changes:
|
I've lowered the python requirement to 3.8.1 and updated the dependencies list. |
Hi @floryst , |
Hi @phtran-dev, One limitation of wslink is that bi-directional RPC is not currently supported, which is necessary to support accessing the client state store from the server. While I could technically add a bi-directional RPC mechanism on top of wslink, it's another layer of complexity and lacks implementation symmetry when compared to using socket.io. Another consideration is that python-socketio is ASGI compatible, so you can integrate this python server into your ASGI-compatible framework (e.g. sanic or fastapi) or server (e.g. uvicorn). I still need to change the docs to using the volview server as an ASGI middleware. I suppose wslink can be made ASGI compatible (if it isn't already), so this is less of a concern. |
Hi @floryst , |
Another point that is important to keep in mind is the fact that wslink is really meant to be used with a dedicated server process per client. And for his reference implementation, @floryst wanted to have a simple server (1 instance that serves many clients). But in general, it might be easier to abstract the VolView client side so a wslink version of that client (with a dedicated server process) could be swapped and used. @floryst do you think you can make sure the client side could be swapped? That way @phtran-dev can still rely on his existing infrastructure by just adding a protocol on his server side. |
I'm not sure about a swappable client yet. My suggestion would be to use an ASGI-compatible framework and register the wslink and volview servers under different routes (e.g. |
Hi @floryst , |
The VUE_APP_REMOTE_SERVER_URL variable in the .env file should also be available in the setting dialog. If this variable must be defined when the app is launched, then changing the variable in the dialog should cause another pop-up that gives the user a button to reload/restart volview with the new setting applied. If a .env file doesn't exist, it should be automatically created - when running from github source. Instead of displaying tabs (e.g., DICOM WEB and Remote Functions) based on a variable being set, we should test the variable and if they work, display the tabs, otherwise don't. Could even put "test" buttons next to those variables in the settings dialog. |
@aylward I force-pushed this branch and updated it to match
@phtran-dev VolView currently doesn't support remote rendering. The server is just for remote data processing and control, so it won't conflict at all with your current remote rendering setup. |
I can only get the median filter to work on the "MRI HEART ... Ax FIESTA non gated" sample data. Running the filter on the other sample images hangs the Python server on the Chrome on Ubuntu |
Same for me on Windows 11 with Edge browser. Median filter works on the image Paul mentioned above but not for any other images. |
This adds support for bidirectional python server integration with VolView.
- Adds medianFilter example
- Remove unused msgpack dependency - add charset-normalizer dependency
- client is accessible via the server store - adds support for restricting client-side property access
- add debug logging - remove max message size option, since we now chunk - fix handling of image direction
- Blob/File.size, not .length - ensure cause is an error - remove non-relevant doc
- Simplifies building VolView APIs, while retaining support for class-based APIs. - Re-worked examples to show both the simple and the class-based APIs. - get_current_session() associates session objects with clients. - median filter example is no longer blocking.
- FastAPI example in docs and in examples/ directory - Add support for custom socket.io paths
847240a
to
fdea45f
Compare
We will re-enable it when the examples are ready.
I aim to merge this in without exposing the Remote tab for now. This will get the core components in, and we can add the Remote tab later once we have everything else in place for it. |
Please do check-in the updated remote tab component though, so we can understand the usage for downstream LungAir. |
Yep, the |
This adds a functional Python server to VolView through the "Remote Functions" tab.
Future demonstrations would include remote-loading of datasets and measurements.