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.

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

Share application detection code with Mission Center? #424

Open
qwertychouskie opened this issue Dec 20, 2024 · 3 comments
Open

Share application detection code with Mission Center? #424

qwertychouskie opened this issue Dec 20, 2024 · 3 comments

Comments

@qwertychouskie
Copy link

When Mission Center rewrote the application detection code a few months ago, it was factored into a standalone crate that can be used by any application: https://gitlab.com/mission-center-devs/app-detection

Using this code would mean that application detection would be consistent between both applications, and any improvements to the shared code would benefit both applications. It might also fix some open app detection issues such as #380 and #402 and perhaps #362. This image was also recently posted in the Mission Center discord server comparing the app detection of Mission Center and Resources:

image

FWIW there are likely also other situations where Resources does better than Mission Center currently does, but ultimately it would be nice if the two projects shared the detection code.

@kicsyromy
Copy link

Just to chime in here, the crate is hosted in the mission-center-devs org, but I would be happy to move it to a neutral location, and change hosting providers if it makes things easier for both parties.

@nokyan
Copy link
Owner

nokyan commented Dec 21, 2024

Hi,
that sounds like a neat idea, I didn't know that Mission Center made app detection a standalone crate. If it fixes Resources' current app detection woes, even better.
It'd probably be a rather big undertaking though, I'll look into it once I've got some other features done.

Just to chime in here, the crate is hosted in the mission-center-devs org, but I would be happy to move it to a neutral location, and change hosting providers if it makes things easier for both parties.

I don't mind that at all, no worries. :)

@qwertychouskie
Copy link
Author

In addition to the app detection code being split out, Mission Center is currently working on splitting out the entire backend "gatherer" code so it can be used by other applications. From our Discord server a couple days ago:

The new repo is ready:
https://gitlab.com/mission-center-devs/gng

It is still incomplete, missing functionality and probably has bugs.
Notable omissions are S.M.A.R.T information and fan information (these are the hardest to port so I left them last)

Highlights:

  • New name: Magpie (can still be changed)
  • New IPC mechanism, no more D-Bus, manual serialization and high latency. We're now using Google's Protobuf to define the data structures that are sent back and forth between Magpie and Mission Center. This gives us a single source of truth that is strongly typed and with generates idiomatic (for the most part) Rust data structures. This is combined with nng (https://github.com/nanomsg/nng) for a fast and easy to use transport mechanism. This brings with it a really cool feature where Magpie can be run on a remote machine but the UI can run locally and connect to the remote instance of Magpie.
  • Fully async (not in the Rust sense), every request that Magpie handles is now replied instantly (with very few exceptions) and all refreshing takes place in the background and does not impact reply latency this should fix any stuttering experienced in the UI
  • Heavily threaded, Magpie now uses a thread pool to refresh the data, which means that things that are slow to refresh have much less an impact on other things. Services are slow to refresh, but they don't impact the how quickly processes refresh, for example.

The hope is that (in addition to the code just being generally cleaner) any system monitor (Mission Center, Resources, Observatory, whatever Gnome cooks up to replace GSM, etc) can use a single backend rather than having every app write a completely separate backend with different features and bugs. We also hope to be able to have the backend run on a different machine to the frontend, e.g. the backend runs on a server and the frontend app can be used to easily connect and monitor the server. In fact, we hope to be able to have it work cross-platform too, so e.g. you could run the frontend app on Windows to monitor a Linux or BSD server.

(BTW, if you want an easier way to chat details, feel free to join out Discord server where most of our development discussion takes place: https://discord.gg/hSvW8BakA2)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants