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.

Sign up for GitHub

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

Jump to bottom

PackageStatus message should define a downloading state and include additional metadata #204

Open
michel-laterman opened this issue Oct 1, 2024 · 2 comments · May be fixed by #206
Open

PackageStatus message should define a downloading state and include additional metadata #204

michel-laterman opened this issue Oct 1, 2024 · 2 comments · May be fixed by #206

Comments

@michel-laterman
Copy link

PackageStatus messages should include an optional DOWNLOADING status that may be used by a client to signal that it is downloading the package.
Additionally we allow for an optional metadata attribute (map[string]string) to allow additional details related to the state to be included, such as a message, download_rate, download_percent, etc.
metadata should also be optional for the existing states (INSTALLED, INSTALLING, INSTALL_FAILED) and may include relevant information.

This will allow users to determine if the install is taking a long time due to a network issue instead of only having the INSTALLING state appear.
@tigrannajaryan
Copy link
Member

I think DOWNLOADING makes sense.

Additionally we allow for an optional metadata attribute (map[string]string) to allow additional details related to the state to be included, such as a message, download_rate, download_percent, etc.

I would like to understand this part better. Is there a reason we keep it an arbitrary open map of attributes instead of standardizing?

@michel-laterman
Copy link
Author

My thought is that a generic map will make it easier for a client to add information about any stage of managing package lifecycles, not just downloading.
This information may be useful to end users but not required for the protocol itself

@michel-laterman michel-laterman linked a pull request Oct 16, 2024 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add downloading state and metadata to PackageStatus michel-laterman/opamp-spec
2 participants
@tigrannajaryan @michel-laterman