search

eclipse-iceoryx / iceoryx2

Eclipse iceoryx2™ - true zero-copy inter-process-communication in pure Rust
https://iceoryx.io
Apache License 2.0
514 stars 26 forks source link

Initial introspection GUI web-app #46

Open flynneva opened 9 months ago

flynneva commented 9 months ago

Brief feature description

Listed on the road map is the desire to create a web app GUI that spins up basic webserver and allows the user to introspect an iceoryx2 system.

Introspection information expected to be displayed would be:

  1. [ ] Active iceoryx2 participants
    1. basic info for each participant like name, up-time, memory usage, etc. (maybe @elfenpiff can list some more requirements here)

A good place to start would be to look at what exists for iceoryx and re-implement it here.

Looking at egui as the basic lib, using eframe as a starting point.

Detailed information

The features of the introspection GUI will be dependent on availability of introspection API's to list required info. We should link other related issues here that relate to creating / enabling introspection APIs so that once they are available the features can be added to the GUI.

flynneva commented 9 months ago

@elfenpiff @elBoberido feel free to assign this one to me. Happy to get a little rusty and try my hand at this 🦀

flynneva commented 9 months ago

Only had time today to get the basic eframe template integrated into the repo here...let me know what crazy name you want to call this GUI....I chose iceoryx2-eye completely randomly so open to suggestions.

elfenpiff commented 9 months ago

@flynneva Oh man you are awesome! I already checked it out, and it looks like the perfect starting point.

I think the GUI version will become something bigger, so I would create a separate repo here in eclipse-iceoryx for this on the long term.

@elBoberido @flynneva we need to ask Mr. Gin and Mr. Tonic during a Mongolian Throat Singing session what their name ideas could be.

Maybe some cool curious animal? iceoryx2-owl? But iceoryx2-eye is also not bad for a random first choice.

elBoberido commented 9 months ago

@flynneva awesome stuff. @elfenpiff and me were discussion whether to use egui or iced. I guess you settled the discussion :)

Regarding the name it depends a little bit on how we want to use it. We had the idea to create some tooling around an iox2 command, similar to ros2. Like with cargo, the user could extend the functionality by just adding iox2-foo binary to a specific path and then the user could run iox2 foo. The question is now whether the GUI is part of this cmd line tools or something completely different. My gut feeling is that it should be something completely different and we are therefore completely free in choosing a name.

For iceoryx1 there is a Rust TUI called iceray. We could reuse that name if you like it. I don't think there are that many users of it so it won't be a big problem to re-purpose it to iceoryx2.

elfenpiff commented 9 months ago

@flynneva @elBoberido I got suddenly the idea of an iceoryx2_command_center which does the same thing as ros2 or cargo does, bundle everything together in one modular, extensible graphical ui.

So I already had the idea that it would be nice to have an iceoryx2 service that provides on a pub/sub channel the things you usually see with htop for instance.

So this command center would be an interactive interface for all iceoryx2 services which are provided by us and can be extended to custom services.

Let's assume in the future with have microservices like a service monitor, system monitor (htop alternative), deep package introspection (something that can subscribe to everything and we can inspect the transmitted data) and a lot more and everything is bundled together in one ui. And when a user wants to add something, the only thing they have to do is to compile some module and then it is added to the ui (no idea how to realize this at the moment).

What do you think?

flynneva commented 9 months ago

@elfenpiff anything is possible. The question is what's necessary.

Whatever iceorxy2 apis are available we can make a widget for. The best design would be to make it modular based on use case...like a service introspection widget, a resource usage widget (like htop), etc. that way the end user can pick and choose which widget they need and nothing more.

I think before we start day dreaming let's first get a MVP of a GUI (literally anything that's usable) and build out different use cases from there.

Before jumping to the moon let's first get off earth 🚀

elBoberido commented 9 months ago

@elfenpiff a cold shiver ran down my back :sweat_smile: ... do you know the NI MAX https://ni.scene7.com/is/image/ni/NI%20MAX?scl=1. It does also show all the connected devices and system information and one can also update the firmware and do more stuff. Except being borderline slow at times, it was quite neat. I even had the idea to implement something similar for the SigMo and PeP-PI devices I once had in mind to develop.

But I agree with @flynneva, let's start small and get an experience with Rust GUIs first. Trying to do too much at once is usually a recipe for disaster.

flynneva commented 9 months ago

@elfenpiff @elBoberido if some system / state info is available via iceoryx2 API's I don't see why we couldn't also display that in a gui widget....just you API wizards would have to direct me to them 😅

I'll see if I can get the services display example running in the gui as a starting point...maybe over the weekend once I'm done traveling.

From there the world is our oyster. 🦪

elBoberido commented 9 months ago

@flynneva hmm oyster could also be a good name for a plugin based introspection GUI :grin: