12-Feb-2025, 09:46 AM
Havn't really reported much about the progress of High End U1. Mainly this next revision is a re-write of the API service (the backend), and re-engineering it to be more asynchronous. The work involved is quite heavy (I really under-estimated the scope of this change) but it's progressing forward I guess.
In the past I'm using cpprestsdk as the library, but in HE U1 this will be replaced with something called Qt (pronounced Cute). This library can do what cpprestsdk do, and more. And that "more" bit is where I under-estimated the time as migrating the code took longer than expected.
The end result is something that's better, but it runs at a higher memory footprint as everything is more complex. I do not know if it's a pro and con at this stage but at this stage because of the way Qt works, the service should be very preempt-able and should work better in a RT kernel.
One added feature is the addition of tests,
And this is something that don't exist before. In the future I will also add a test to ensure the players installation continue to work (in new updates). Basically the tests allow me to establish a "baseline" and it will improve over time.
With the introduction of Qt, it also means it's possible to have a graphical (or text) UI to control the Snakeoil machine (independent of the WebApp). I don't know whether to go with a text interface or a graphical one at this stage. In theory a graphical one is more preempt-able but the cost again is more memory is used. And because I'm using Qt now, it's possible to write dedicated applications (on desktops and mobiles) that can interact directly with the Snakeoil machine.
And perhaps, Snakeoil will have it's own player in the future.
Sounds exciting? Just unsure how long this will take.
In the past I'm using cpprestsdk as the library, but in HE U1 this will be replaced with something called Qt (pronounced Cute). This library can do what cpprestsdk do, and more. And that "more" bit is where I under-estimated the time as migrating the code took longer than expected.
The end result is something that's better, but it runs at a higher memory footprint as everything is more complex. I do not know if it's a pro and con at this stage but at this stage because of the way Qt works, the service should be very preempt-able and should work better in a RT kernel.
One added feature is the addition of tests,
Code:
test project /home/snakeoil/src/operating-system/.rest_build/tests
Test #1: service_system
Test #2: service_database
Test #3: service_library
Test #4: service_players
Test #5: service_version
Test #6: service_os
Total Tests: 6With the introduction of Qt, it also means it's possible to have a graphical (or text) UI to control the Snakeoil machine (independent of the WebApp). I don't know whether to go with a text interface or a graphical one at this stage. In theory a graphical one is more preempt-able but the cost again is more memory is used. And because I'm using Qt now, it's possible to write dedicated applications (on desktops and mobiles) that can interact directly with the Snakeoil machine.
And perhaps, Snakeoil will have it's own player in the future.
Sounds exciting? Just unsure how long this will take.
Snakeoil Operating System - Music, your way!
thanks
![[-]](https://forums.snakeoil-os.net/images/collapse.png "[-]")
