Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Roadmap #1

Open
38 of 66 tasks
jourdain opened this issue Jun 11, 2021 · 6 comments
Open
38 of 66 tasks

Roadmap #1

jourdain opened this issue Jun 11, 2021 · 6 comments

Comments

@jourdain
Copy link
Collaborator

jourdain commented Jun 11, 2021 •
edited
Loading

  • VTK/master (~10.0.0) available as wheel
    • X server
    • EGL
    • OSMesa
  • WSLink - Py3 async/await
    • Better core framework (Tornedo/aiohttp/?)
    • Transport compression
    • Application compression
    • Async built-in
  • ParaView (nightly/release)
    • VTK
    • WSLink
  • More public application using it
    • SandTank XAI
    • Conceptual Modeler (GemPy++)
    • Visualizer -> ParaViewWeb
    • ...
  • PyWebVue features
    • Method calls
      • Python => JS
      • JS => Python
    • State synchronization
      • Regular object (dict, string, number, ...)
      • Files
      • TypedArray/Numpy with attachment usage
      • Compression per message
    • Dynamic add-on behavior
      • Server protocols registration
        • Visualizer could the illustration of it
      • Client behavior add on (store, behavior, wsClient-protocols)
        • Visualizer could the illustration of it
    • Deployment
      • Multi-clients built-in
        • Launcher multi-ports
        • Launcher with dynamic proxying
      • Setup for docker / singularity deployment
        • Create a directory structure similar to was our generic PVW docker image expect
        • Update our generic docker image to support such deployment
        • Singularity usage?
      • Integration into XXX service offering
  • Documentation
    • Main readme up to date
    • Documentation web site
    • Examples
      • VTK
        • Local rendering
        • Local rendering from remote vtkRenderWindow synchronization
        • Remote rendering
        • Dynamic Local/Remote rendering switching
      • ParaView
        • Local rendering
        • Local rendering from remote vtkRenderWindow synchronization
        • Remote rendering
        • Dynamic Local/Remote rendering switching
      • Real sample application
        • Picking (vtk-f1)
        • Widgets
        • File upload / decoding (vtk-fea)
        • ...
  • Testing
    • Create testing framework
    • Setup CI testing
  • Release
    • Semantic release managed in CI
      • PyPI (Python)
      • npm (JS)
@patrickoleary
Copy link
Member

Awesome! I can't wait.

@aaronchn
Copy link

What a great！

@jourdain
Copy link
Collaborator Author

@aaronchn you should checkout trame which is really a nice abstraction layer on top of py-web-vue. In reality py-web-vue will be break down into smaller pieces and renamed trame-core, trame-widgets-vuetify, trame-widgets-*. Of course trame will only switch its internal import but it will keep the same API (so no breaking changes at the trame level). This will allow us to better manage client/server code compatibility.

@aaronchn
Copy link

@jourdain

As a novice with no web development experience, after reading the py-web-vue readme, I had the following possibly vague or incorrect perceptions：

SharedState is a core concept in trame or py-web-vue. This concept is a strong contender for the current client(data drive UI)<->ajax call<->restfull api(maybe like Flask) development pattern, and can even be called revolutionary.

The SharedState based web development pattern removes the clear boundary between client and server to some extent, which can be great, but there is an inertia in understanding the traditional web app pattern when trying or practicing it. This inertia may be a barrier to learning py-web-vue.

The SharedState based web development model somehow reduces the difficulty of web app development, or the skills required to get started.

SharedState based web development pattern, for the front and back-end close interaction scenario, such as VTK (I do not know this) may be very suitable, but can it basically or completely replace Django or Flask such web framework? I'm looking forward to seeing successful examples of this, which could be a boon to small or non-professional web developers.

Sorry, I haven't read the Trame documentation yet, so I'm not sure what the important differences are between the trame and py-web-vue projects, I'll try to learn more.

I don't mean to discredit the vue.py project, but as far as I understand it now, py-web-vue might be a more suitable choice for developing small webapp needs, so I hope I'm right.

Interesting, great, thank you!

@jourdain
Copy link
Collaborator Author

@aaronchn your summary on the shared state is fairly accurate and you are right of being "revolutionary".

But they are things to note and be aware of. pywebvue/trame are mainly driven for building stateful applications which is not what you get with flask/django. It is really for building application like you find on your desktop which can then be use as a local, remote application or a service.

The main difference between pywebvue and trame is that:

  • In pywebvue, you write Python + HTML + state and you need to keep things in sync (trigger names...)
  • With trame, you just write Python that build the HTML+state for you and make sure things are in sync.

HTH

@jourdain
Copy link
Collaborator Author

jourdain commented Mar 17, 2022 •
edited
Loading

You can see the code difference between pywebvue and trame for a simple examples

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jourdain @patrickoleary @aaronchn