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

[Refactor]: Success/Failure Responses #612

Open
Nukesor opened this issue Feb 16, 2025 · 0 comments
Open

[Refactor]: Success/Failure Responses #612

Nukesor opened this issue Feb 16, 2025 · 0 comments
Labels
f: Breaking Change This is a breaking change and needs a major version release f: Help wanted s: Client This issue touches the pueue client s: Daemon This issue touches pueue daemon s: Pueue-lib This issue touches the pueue-lib library

Comments

@Nukesor
Copy link
Owner

Nukesor commented Feb 16, 2025

The idea for this is to return structured data in daemon responses instead of just sending a compiled string that's then displayed to the user.

This would entail a much cleaner API design and allow clients to better integrate with the daemon, as response data can be inspected programatically.

However, this comes with the challenging task to create a good API message structure that's able to reflect all kinds of errors, partial errors with lists of successful and failed tasks (e.g. the user pauses some tasks but some are already finished) , and successful messages.

These response types and error types should then also have a way to be conveniently Displayed as text.

Furthermore, I want this to be somewhat "generic". Not necessarily in the sense of actual generics, but rather that we don't create a single return message for every subcommand (i.e. KillResponse, StartResponse, etc), which makes this a lot trickier.

A good first task would probably to investigate all messages that're sent in the daemon/network/message_handler/ files and create a "mindmap" of some sorts. Based on that overview, we could go ahead and try to find common patterns that allow us to create a minimalistic API structure that's capable of handling all error cases.

This change can be backwards compatible in the sense that the client may still be able to interpret old-style messages. It would only be breaking if a new daemon talks with an old client.

@Nukesor Nukesor added s: Client This issue touches the pueue client s: Daemon This issue touches pueue daemon s: Pueue-lib This issue touches the pueue-lib library labels Feb 16, 2025
@Nukesor Nukesor self-assigned this Feb 16, 2025
@Nukesor Nukesor changed the title [Refactor]: Responses [Refactor]: Success/Failure Responses Feb 16, 2025
@Nukesor Nukesor removed their assignment Feb 16, 2025
@Nukesor Nukesor added f: Help wanted f: Breaking Change This is a breaking change and needs a major version release labels Feb 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
f: Breaking Change This is a breaking change and needs a major version release f: Help wanted s: Client This issue touches the pueue client s: Daemon This issue touches pueue daemon s: Pueue-lib This issue touches the pueue-lib library
Projects
None yet
Development

No branches or pull requests

1 participant