Roadmap

[jourdain]

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

[patrickoleary]

Awesome! I can't wait.

[aaronchn]

What a great！

[jourdain]

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

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

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

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

• vtk.js cone PyWebVue / trame
• VTK with local rendering PyWebVue / trame