Proposal: Structured progress messages for SWUpdate / hawkBit UI integration

[Ihor Fedorenco]

Hi Stefano,

I’m continuing the discussion from the hawkBit thread:
https://github.com/eclipse-hawkbit/hawkbit/issues/2868#issuecomment-4191718757

Following the feedback there, it seems clear that extending hawkBit backend for progress reporting is not aligned with its architecture (DB impact, DDI load, etc.).

Given that, I’m exploring an alternative approach on the device + UI side, and I would like your opinion.

Since hawkBit already supports arbitrary details/messages, would it make sense to standardize a lightweight, structured message format for reporting device-side progress from SWUpdate?

For example:

progress phase=download percent=45 progress phase=install percent=12 progress phase=done percent=100

The idea is:

• SWUpdate / suricatta emits structured progress messages via details

• hawkBit stores them unchanged

• hawkbitUI (or other clients) optionally parses and visualizes progress

This would:

• avoid any backend or DB changes in hawkBit

• stay fully backward compatible

• provide a consistent way to expose progress for headless devices

• improve over ad-hoc messages like “Downloaded 45%”

From the SWUpdate perspective, this seems like a small addition (formatting existing progress into a consistent structure), but it could significantly improve integration with hawkBit UI and similar tools.

Do you think such a convention would be acceptable for SWUpdate (even as an optional feature)?

[Stefano Babic]

Hu Fedorenco,

On 4/6/26 14:38, Ihor Fedorenco wrote:
> Hi Stefano,
>
> I’m continuing the discussion from the hawkBit thread:
> https://github.com/eclipse-hawkbit/hawkbit/

> issues/2868#issuecomment-4191718757 <https://github.com/eclipse-hawkbit/
> hawkbit/issues/2868#issuecomment-4191718757>

>
> Following the feedback there, it seems clear that extending hawkBit
> backend for progress reporting is not aligned with its architecture (DB
> impact, DDI load, etc.).

Hawkbit does not allow to send a lot of logs - there is some specific
set up in SWUpdate to split logs in parts and to overcome Hawkbit
limitations.

>
> Given that, I’m exploring an alternative approach on the *device + UI
> side*, and I would like your opinion.

>
> Since hawkBit already supports arbitrary details/messages, would it make
> sense to standardize a lightweight, structured message format for
> reporting device-side progress from SWUpdate?
>
> For example:
>
> progress phase=download percent=45 progress phase=install percent=12
> progress phase=done percent=100
>

But well, this is *already* done and used, so I do not know what you want.

This is part of "Feedback channel for the DeploymentBase action "

The anser is already a structured message as specifie4d by the API:

{

"status": {
"execution": "closed",
"result": {
"finished": "success",
"progress": {
"cnt": 2,
"of": 5
}
},
"code": 200,
"details": []
},
"timestamp": 1627997501890

}

And SWUpdate sends *exactly* this message. SWUpdate uses the "details"
to push its logs, and this can be opened in the Hawkbit's GUI.

> The idea is:
>
> *

>
> SWUpdate / suricatta emits structured progress messages via details
>

It is already done, but Hawkbit doesn't parse it. Details[] contain the
logs.

> *
>
> hawkBit stores them unchanged
>
> *

>
> hawkbitUI (or other clients) optionally parses and visualizes progress
>

Logs are already shown in the GUI.

> This would:
>
> *

>
> avoid any backend or DB changes in hawkBit
>

> *
>
> stay fully backward compatible
>
> *

>
> provide a consistent way to expose progress for headless devices
>

> *

>
> improve over ad-hoc messages like “Downloaded 45%”
>
> From the SWUpdate perspective, this seems like a small addition
> (formatting existing progress into a consistent structure), but it could
> significantly improve integration with hawkBit UI and similar tools.
>
> Do you think such a convention would be acceptable for SWUpdate (even as
> an optional feature)?

The details[] array was already used, SWUpdate sends a structured
message, and logs are already shown by the GUI. However, the progress
data are ignored by Hawkbit.

Best regards,
Stefano Babic


--
_______________________________________________________________________
Nabla Software Engineering GmbH
Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596
Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
E-Mail: sba...@nabladev.com

[Ihor Fedorenco]

thank you for the clarification — that helped a lot to understand the current behavior.

Yes, I see that SWUpdate already sends structured progress (cnt/of) and that logs (details[]) are available and shown in hawkBit.

What I’m trying to address is slightly different — more on the UI/UX side for headless devices.

In scenarios with:

• large artifacts
• slow or unstable connections
• no local UI on the device

it becomes important to have a clear, visual representation of progress (download/install), similar to what SWUpdate provides locally (web UI / display).

At the moment:

• structured progress (cnt/of) is not exposed by hawkBit
• logs can contain progress, but require higher verbosity and parsing
• the UI does not provide a consolidated “device progress view”

So the question is:

within the current architecture, what would be the recommended way to surface a concise, visual progress state in hawkBit UI?

For example:

• download progress bar
• install phase indication
• possibly artifact-level progress

without relying on verbose logs or backend changes
for example to extend target with progress column

To give a concrete example from the UI perspective:

it could be useful to extend the target table with a simple “Progress” column, showing a concise device state derived from feedback.

This would provide a quick, at-a-glance view for headless devices (especially with large artifacts or slow connections), without requiring users to open logs and inspect detailed messages.

Very simplified image:

Best regards
Ihor, 

середа, 8 квітня 2026 р. о 15:55:50 UTC+3 Stefano Babic пише:

[Stefano Babic]

Hi Ihor,

On 4/8/26 16:57, Ihor Fedorenco wrote:
> thank you for the clarification — that helped a lot to understand the
> current behavior.
>
> Yes, I see that SWUpdate already sends structured progress (cnt/of) and
> that logs (details[]) are available and shown in hawkBit.

This is generally enough.

>
> What I’m trying to address is slightly different — more on the *UI/UX
> side for headless devices*.
>
> In scenarios with:
>
> * large artifacts

=> always

> * slow or unstable connections

=> often

> * no local UI on the device

==> if we have Hawkbit, a device can have a HMI, but it is not accessible

So there is nothing new - this is a common scenario.

>
> it becomes important to have a clear, visual representation of progress
> (download/install), similar to what SWUpdate provides locally (web UI /
> display).

Well, I just provide the differences. Using SWUpdate's WebUI, the
software is pushed to the device in the same timeline when the display
is showed. Sure having a display or Webbrowser to show the progress is
very comfortable, but it is also a different use case.

With Hawkbit, we have generally rollouts. We want to provide updates for
thousands of devices. Devices maybe polls the server once a day, so
constantly looking at the progress makes less sense. The update itself
can run slowly, because bandwidth is maybe limited. What is important is
to get if an update fails (and this is reported by Hawkbit), and when it
happens, to get the logs to identify the reason (and this is done as well).

Consider also that SWUpdate is not allowed to send constantly logs to
the Hawkbit server. The default value in application.properties for
Hawkbit is very restrictive. There is a DOS (deny of service) property
in the Hawkbit server, and if SWUpdate sends too many messages, they are
silently dropped. So from design, Hawkbit's developers do not want to
have a lot of data coming from the device.

To have a functional progress, SWUpdate should send continuously new
data when something is changed. For example, percentage of downloaded
data (1..100), progress bar for each step, etc. All these information
are sent via the progress interface and the internal Webserver sends via
Websocket to any connected browser. Then yes, the visual representation
(WebUI / local) is responsive.

I guess that what is disturbing for the Hawkbit's developers is that
they cannot then control how much traffic the devices will generate.

>
> At the moment:
>
> * structured progress (cnt/of) is not exposed by hawkBit

But it is also not exposed to the REST API, so the GUI has no access.

> * logs can contain progress, but require higher verbosity and parsing
> * the UI does not provide a consolidated “device progress view”

Ok, let's see what I can discuss on my side.

- Hawkbit API: this cannot be changed if developers do not agree and
they do not agree.

- SWUpdate: this can be extended
- HawkbitGUI: this can be extended and we can make what we want, but we
have to use the REST API. At the moment, the GUI resembles the features
of the old GUI (until Hawkbit 0.4), but sure it can have another UX.

>
> So the question is:
>
> within the current architecture, what would be the recommended way to

> surface a *concise, visual progress state* in hawkBit UI?
>
> For example:
>
> * download progress bar
> * install phase indication
> * possibly artifact-level progress

>
> without relying on verbose logs or backend changes

I can change SWUpdate and the GUI. But in any case, this raises more
traffic (and it is an issue on lowband connection, mobile, GSM, etc.)

It will be nice to send logs just on demand, that is if Update fails,
but there is not REST API for this.

> for example to extend target with progress column
>
> To give a concrete example from the UI perspective:
>
> it could be useful to extend the target table with a simple “Progress”
> column, showing a concise device state derived from feedback.
> > This would provide a quick, at-a-glance view for headless devices

If we are using Hawkbit, all of them are headless, even the ones from
display. But how can we differentiate in base of bandwidth requirements ?

> (especially with large artifacts or slow connections), without requiring
> users to open logs and inspect detailed messages.
>

Targets are also loaded - that means, if the progress is always shown,
this causes a massive amount of data during the scroll of the target
window. And if I remember well, the targets must be individually asked,
that means each of them cause an additional GET to the server.

Best regards,
Stefano Babic

> Very simplified image:
>
> Best regards
> Ihor,
>
> середа, 8 квітня 2026 р. о 15:55:50 UTC+3 Stefano Babic пише:
>
> Hu Fedorenco,
>
> On 4/6/26 14:38, Ihor Fedorenco wrote:
> > Hi Stefano,
> >
> > I’m continuing the discussion from the hawkBit thread:

> > https://github.com/eclipse-hawkbit/hawkbit/ <https://github.com/
> eclipse-hawkbit/hawkbit/>
> > issues/2868#issuecomment-4191718757 <https://github.com/eclipse-
> hawkbit/ <https://github.com/eclipse-hawkbit/>

> Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:
> +49%20821%2045592596>

> Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> E-Mail: sba...@nabladev.com
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/bbd2955b-9e7b-45af-8d27-bd8f037a8c60n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/bbd2955b-9e7b-45af-8d27-
> bd8f037a8c60n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ihor Fedorenco]

Hi Stefano,
thanks, this clarifies the concern about scalability and data access.
I understand now that the main limitation is not the data itself, but how it is accessed:

•     /status is available per target
•     but fetching it for all targets (or during scrolling) would lead to too many requests
•     so any UI feature must avoid per-target polling in the table view

Given that, I see the following constraints:

•     no additional requests per target while rendering the table
•     logs should be fetched only on demand or in a controlled manner (as currently done)

So instead of fetching logs for every target, a possible approach would be:

•     keep the table view based on already available data
•     optionally enrich only a limited subset of targets (e.g. active updates or a selected target)
•     cache /status results and avoid repeated requests

In this model:

•     no additional load is introduced during scrolling
•     logs remain the source of truth and are still accessed on demand
•     the UI can provide a lightweight, best-effort summary only where relevant

Does this approach align better with the design constraints,
or would you recommend avoiding this entirely and keeping the UI strictly log-based?

середа, 8 квітня 2026 р. о 20:00:32 UTC+3 Stefano Babic пише:

[Stefano Babic]

Hi Ihor,

On 4/9/26 14:32, Ihor Fedorenco wrote:
> Hi Stefano,

> thanks, this clarifies the concern about scalability and data access.
> I understand now that the main limitation is not the data itself, but
> how it is accessed:
>

> *     /status is available per target
> *     but fetching it for all targets (or during scrolling) would

> lead to too many requests

> *     so any UI feature must avoid per-target polling in the table view
>

There is not a group API. So there is a GET to retrieve the list of
target, one to get the list of actions for each target and then it is
possible to run the GET for a target and a specific action.

> Given that, I see the following constraints:
>

> *     no additional requests per target while rendering the table
> *     logs should be fetched only on demand or in a controlled manner
> (as currently done)
>

This is already supported, and it is how it is currently implemented.
You have to select a target to get the logs.

> So instead of fetching logs for every target, a possible approach would be:
>

> *     keep the table view based on already available data
> *     optionally enrich only a limited subset of targets (e.g. active

> updates or a selected target)

> *     cache /status results and avoid repeated requests
>

To do what ?

The /status API does not report what SWUpdate has sent. We get:


PagedListMgmtActionStatus{
content* [MgmtActionStatus{
id [...]
type [...]
messages [...]
reportedAt [...]
timestamp [...]
code [...]
}]

> In this model:
>
> *     no additional load is introduced during scrolling
> *     logs remain the source of truth and are still accessed on demand
> *     the UI can provide a lightweight, best-effort summary only

It is not clear to me what you are proposing.

> where relevant
>
> Does this approach align better with the design constraints,
> or would you recommend avoiding this entirely and keeping the UI
> strictly log-based?

Best regards,
Stefano Babic

> github.com/eclipse-hawkbit/hawkbit/> <https://github.com/ <https://
> github.com/>
> > eclipse-hawkbit/hawkbit/>
> > > issues/2868#issuecomment-4191718757 <https://github.com/
> eclipse- <https://github.com/eclipse->
> > hawkbit/ <https://github.com/eclipse-hawkbit/ <https://

> +49%20821%2045592596> <tel:

> > +49%20821%2045592596>
> > Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> > E-Mail: sba...@nabladev.com
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > swupdate/bbd2955b-9e7b-45af-8d27-bd8f037a8c60n%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/swupdate/
> bbd2955b-9e7b-45af-8d27- <https://groups.google.com/d/msgid/
> swupdate/bbd2955b-9e7b-45af-8d27->
> > bd8f037a8c60n%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?

> utm_medium=email&utm_source=footer>>.
>
> --
> _______________________________________________________________________
> Nabla Software Engineering GmbH

> Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:
> +49%20821%2045592596>
> Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> E-Mail: sba...@nabladev.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> swupdate/853dcf5a-c665-4ec4-a621-8656b6b7771fn%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4-
> a621-8656b6b7771fn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ihor Fedorenco]

Hi Stefano,
thank you for your time and for the detailed explanations so far.

and 
let me restate the requirement clearly:
the goal is to show percentage-based progress (e.g. download / install % / count of artifacts) in the UI.
From what I understand:

•  hawkBit does not expose structured progress via REST
•  continuous updates via logs are limited and not reliable
•  additional polling or frequent updates are not acceptable due to scalability constraints

So it seems that accurate percentage-based progress is not supported by design.
At the same time, this is a requirement to improve.
So I would like to ask directly:
    within these constraints, do you see any acceptable way to approximate progress in the UI, even as a best-effort solution?
For example, using:

•  sparse signals from logs
•  coarse milestones
•  or any other approach that would not increase load or interfere with existing behavior

Or should this be considered out of scope for hawkBit entirely?
This will help me decide whether to:

• implement a local workaround, or
• design a separate solution for progress monitoring.

четвер, 9 квітня 2026 р. о 17:44:15 UTC+3 Stefano Babic пише:

[Stefano Babic]

Hi Ihor,

On 4/10/26 09:12, Ihor Fedorenco wrote:
> Hi Stefano,

> thank you for your time and for the detailed explanations so far.
>
> and
> let me restate the requirement clearly:
> the goal is to show percentage-based progress (e.g. download / install
> % / count of artifacts) in the UI.
> From what I understand:
>

> *  hawkBit does not expose structured progress via REST
> *  continuous updates via logs are limited and not reliable
> *  additional polling or frequent updates are not acceptable due to

> scalability constraints
>
> So it seems that accurate percentage-based progress is not supported by
> design.
> At the same time, this is a requirement to improve.
> So I would like to ask directly:
>     within these constraints, do you see any acceptable way to
> approximate progress in the UI, even as a best-effort solution?

The most efficient way is to have a REST that collects status for
multiple targets. Something like:

http://localhost:53002/rest/v1/targets/targets/action/status

where as query parameter the list of targets is sent, that corresponds
to the targets that are currently showed on the table in the GUI.

> For example, using:
>
> *  sparse signals from logs
> *  coarse milestones
> *  or any other approach that would not increase load or interfere
> with existing behavior
>

If there is no way to improve the REST API, a "work-around" SWUpdate
sends first as mfirst message in "details" a JSON formatted string with
the progress status. This allows to have a nice view, but the point is
that each showed target (or selected target, better) generates a GET to
the server. Not really efficient. I cannot say if the UX will be enough
responsive, or what should be done. The GUI must then polls the server
continouosly, it is also something to be tested.

> Or should this be considered out of scope for hawkBit entirely?

For Hawkbit developers this is not a priority. I do not know if someone
(are you planning to do this ?) post a patch to the Hawkbit server to
extend the REST, if this will be merged. It is something that must be
verified before starting.

> This will help me decide whether to:
>

> * implement a local workaround, or

What is a local workaround if device is headless and nothing can be
displayed ?

> * design a separate solution for progress monitoring.
>

Does it mean a different server, new protocol, etc. ? This is
overkilling IMHO.

Best regards,
Stefano Babic

> > github.com/eclipse-hawkbit/hawkbit/ <http://github.com/eclipse-
> hawkbit/hawkbit/>> <https://github.com/ <https://github.com/> <https://
> > github.com/ <http://github.com/>>
> > > eclipse-hawkbit/hawkbit/>
> > > > issues/2868#issuecomment-4191718757 <https://github.com/
> <https://github.com/>
> > eclipse- <https://github.com/eclipse- <https://github.com/eclipse->>

> > > hawkbit/ <https://github.com/eclipse-hawkbit/ <https://

> github.com/eclipse-hawkbit/> <https://
> > github.com/eclipse-hawkbit/ <http://github.com/eclipse-hawkbit/>>>

> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>>
> > > swupdate/bbd2955b-9e7b-45af-8d27-
> bd8f037a8c60n%40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <https://groups.google.com/d/msgid/swupdate/ <https://
> groups.google.com/d/msgid/swupdate/>
> > bbd2955b-9e7b-45af-8d27- <https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/>
> > swupdate/bbd2955b-9e7b-45af-8d27->
> > > bd8f037a8c60n%40googlegroups.com <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?

> > utm_medium=email&utm_source=footer>>.
> >
> > --
> >
> _______________________________________________________________________
> > Nabla Software Engineering GmbH
> > Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:

> +49%20821%2045592596> <tel:
> > +49%20821%2045592596>
> > Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> > E-Mail: sba...@nabladev.com
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/>

> > swupdate/853dcf5a-c665-4ec4-a621-8656b6b7771fn%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4-
> <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4->
> > a621-8656b6b7771fn%40googlegroups.com?

> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
> --
> _______________________________________________________________________
> Nabla Software Engineering GmbH
> Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:
> +49%20821%2045592596>
> Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> E-Mail: sba...@nabladev.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> swupdate/e7a5030b-ed45-4d06-a6d5-cc91dbea633dn%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/e7a5030b-ed45-4d06-a6d5-
> cc91dbea633dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ihor Fedorenco]

Hi Stefano,
thanks — I think there was a misunderstanding in my previous message.
By “local workaround” I did NOT mean something on the device (like a local UI or display).
What I meant was:
a workaround within the existing hawkBit communication flow,
by reusing the `details[]` field to transport structured progress information (e.g. JSON), and then parsing it in the UI.
So effectively:
* SWUpdate sends structured progress inside `details[]`
* hawkBit stores it unchanged
* the UI interprets it
No additional APIs or protocols involved.

Separately, when I mentioned “a separate solution”, I meant introducing an additional telemetry channel outside hawkBit (which I understand you consider overkill).

>For Hawkbit developers this is not a priority. I do not know if someone
>(are you planning to do this ?)

Given the effort required to extend the REST API and my current limitations on the backend side(hawkbit, DB, N+1 request problem),
I will proceed with the `details[]`-based approach as a best-effort solution.
I understand this is not a perfect or fully scalable solution, but it should be sufficient for our use case.

Thanks again for the guidance — it helped to choose a realistic path forward.

субота, 11 квітня 2026 р. о 12:30:40 UTC+3 Stefano Babic пише:

[Stefano Babic]

Hi Ihor,

On 4/12/26 11:19, Ihor Fedorenco wrote:
> Hi Stefano,

> thanks — I think there was a misunderstanding in my previous message.
> By “local workaround” I did NOT mean something on the device (like a
> local UI or display).
> What I meant was:
> a workaround within the existing hawkBit communication flow,
> by reusing the `details[]` field to transport structured progress
> information (e.g. JSON), and then parsing it in the UI.

Ok

> So effectively:
> * SWUpdate sends structured progress inside `details[]`
> * hawkBit stores it unchanged
> * the UI interprets it
> No additional APIs or protocols involved.
>
> Separately, when I mentioned “a separate solution”, I meant introducing
> an additional telemetry channel outside hawkBit (which I understand you
> consider overkill).

This opens a lot of security issues, that are already solved using Hawkbit.

>
> >For Hawkbit developers this is not a priority. I do not know if someone
> >(are you planning to do this ?)
> Given the effort required to extend the REST API and my current
> limitations on the backend side(hawkbit, DB, N+1 request problem),
> I will proceed with the `details[]`-based approach as a best-effort
> solution.
> I understand this is not a perfect or fully scalable solution, but it
> should be sufficient for our use case.
>

Ok

Please do not forget that SWUpdate and the hawkbitGUI are both GPL
licensed projects, and if you extend them please consider to post and/or
public these changes.

> Thanks again for the guidance — it helped to choose a realistic path
> forward.

You're welcome.

Best regards,
Stefano Babic

> hawkbit/hawkbit/> <http://github.com/eclipse- <http://github.com/
> eclipse->

> > hawkbit/hawkbit/>> <https://github.com/ <https://github.com/>
> <https://github.com/ <https://github.com/>> <https://

> > > github.com/ <http://github.com/> <http://github.com/ <http://

> github.com/>>>
> > > > eclipse-hawkbit/hawkbit/>
> > > > > issues/2868#issuecomment-4191718757 <https://github.com/
> <https://github.com/>
> > <https://github.com/ <https://github.com/>>

> > > eclipse- <https://github.com/eclipse- <https://github.com/

> eclipse-> <https://github.com/eclipse- <https://github.com/eclipse->>>
> > > > hawkbit/ <https://github.com/eclipse-hawkbit/ <https://
> github.com/eclipse-hawkbit/> <https://
> > github.com/eclipse-hawkbit/ <http://github.com/eclipse-hawkbit/>>
> <https://
> > > github.com/eclipse-hawkbit/ <http://github.com/eclipse-hawkbit/

> > <http://github.com/eclipse-hawkbit/ <http://github.com/eclipse-

> > msgid/ <https://groups.google.com/d/msgid/ <https://

> groups.google.com/d/msgid/>>
> > > <https://groups.google.com/d/msgid/ <https://groups.google.com/

> d/msgid/> <https://groups.google.com/d/ <https://groups.google.com/d/>

> > msgid/>>
> > > > swupdate/bbd2955b-9e7b-45af-8d27-
> > bd8f037a8c60n%40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>
> > > <http://40googlegroups.com <http://40googlegroups.com>
> <http://40googlegroups.com <http://40googlegroups.com>>>
> > > > <https://groups.google.com/d/msgid/swupdate/ <https://

> groups.google.com/d/msgid/swupdate/> <https://
> > groups.google.com/d/msgid/swupdate/ <http://groups.google.com/d/
> msgid/swupdate/>>
> > > bbd2955b-9e7b-45af-8d27- <https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>>
> > > swupdate/bbd2955b-9e7b-45af-8d27->
> > > > bd8f037a8c60n%40googlegroups.com <http://40googlegroups.com>

> <http://40googlegroups.com <http://40googlegroups.com>>?

> > > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>?
> > > utm_medium=email&utm_source=footer>>.
> > >
> > > --
> > >
> >
> _______________________________________________________________________
> > > Nabla Software Engineering GmbH
> > > Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:
> +49%20821%2045592596> <tel:

> > +49%20821%2045592596> <tel:
> > > +49%20821%2045592596>
> > > Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> > > E-Mail: sba...@nabladev.com
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "swupdate" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > send
> > > an email to swupdate+u...@googlegroups.com
> > > <mailto:swupdate+u...@googlegroups.com>.
> > > To view this discussion visit https://groups.google.com/d/
> msgid/ <https://groups.google.com/d/msgid/>
> > <https://groups.google.com/d/msgid/ <https://groups.google.com/d/
> msgid/>>

> > > swupdate/853dcf5a-c665-4ec4-
> a621-8656b6b7771fn%40googlegroups.com <http://40googlegroups.com>
> > <http://40googlegroups.com <http://40googlegroups.com>>
> > > <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4-
> <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4->
> > <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4-
> <https://groups.google.com/d/msgid/swupdate/853dcf5a-c665-4ec4->>
> > > a621-8656b6b7771fn%40googlegroups.com <http://40googlegroups.com>?

> > utm_medium=email&utm_source=footer <http://40googlegroups.com
> <http://40googlegroups.com>?
> > utm_medium=email&utm_source=footer>>.
> >
> > --
> >
> _______________________________________________________________________
> > Nabla Software Engineering GmbH
> > Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596 <tel:
> +49%20821%2045592596> <tel:
> > +49%20821%2045592596>
> > Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
> > E-Mail: sba...@nabladev.com
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "swupdate" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to swupdate+u...@googlegroups.com
> > <mailto:swupdate+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> <https://groups.google.com/d/msgid/>

> > swupdate/e7a5030b-ed45-4d06-a6d5-cc91dbea633dn%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/swupdate/e7a5030b-ed45-4d06-
> a6d5- <https://groups.google.com/d/msgid/swupdate/e7a5030b-
> ed45-4d06-a6d5->
> > cc91dbea633dn%40googlegroups.com?

> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>
> --

> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> swupdate/a0ffccb7-4869-41e8-bc88-fe20847d758cn%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/a0ffccb7-4869-41e8-bc88-
> fe20847d758cn%40googlegroups.com?utm_medium=email&utm_source=footer>.