I would prefer http_server, stressing this is about HTTP while tedge is obvious in the context of tedge-agent.

Will be renamed as suggested, right before merging this PR.

Why not simply file_transfer?

I've renamed it as you suggested.

It actually started with entity_store_controller, as I didn't want to name it entity_store to differentiate this from the original entity store and hence ended up adding the controller suffix. Did the the same for file_transfer as well.

But, now I'm wondering if naming them file_transfer_service and entity_store_service would have been clearer/better.

This is out-of-scope of this PR, but we must really find a way to support non default topic-id schema.

There are now two slightly different definitions of struct EntityMetadata; the former definition has been kept in entity_store.rs.

What's the plan?

As mentioned in #3230 (comment), the entity store and entity cache needs to maintain their own versions of entity metadata as the latter would be much lighter with minimal metadata maintained at the mapper level. Ideally the EntityMetadata maintained by the mapper should have been as minimal as the XID. But, I was forced to store a bit more info like the entity type, display name and display type just because of the way we map service health status messages by publishing the service creation message itself(which requires all that metadata) for status updates as well. One way to eliminate caching this additional metadata at the mapper level is by making it query the entity store contents from the agent, whenever it requires all that metadata. But that extra HTTP call during the mapping complicates the conversion logic and I just chose caching extra metadata instead of that added complexity. But, open to revisit that decision in a follow-up PR dedicated for that change as the unit test impact would be quite big.

But that extra HTTP call during the mapping complicates the conversion logic and I just chose caching extra metadata instead of that added complexity.

Agree, caching registration messages is simpler than late-requests to the entity store.

But could we share the type of cached data? Say raw registration messages? Even if some fields are not currently used in the mapper.

But could we share the type of cached data? Say raw registration messages? Even if some fields are not currently used in the mapper.

Yeah, that is an option. I introduced a different struct to clearly represent the minimal set of things that a mapper would need to do the mapping. And also, there were minor things like the external id (@id) being an Option in the actual EntityRegistrationMessage, but the same being a mandatory field in the entity cache. But yeah, if we want to avoid having too many "metadata representations" across the crates, I can reuse some of the existing ones with implicit assumptions about fields like @id.

We really have to reduce the number of similar but different structs.

Resolved by 8751a76 . Even though a single struct is easier to maintain, I'm still tempted to introduce a dedicated EntityMetadataDto struct to capture the message payloads, without overloading this internal EntityMetadata representation with serde aspects. By using the same struct for everything, I'm a bit worried that it'll make future changes to this internal metadata representation more difficult as it'd affect the external representation as well.

I don't fully get your concerns.

• The extra lines for serde are minimal and only related to naming.
• Is this really using the same struct for everything? These metadata are exchanged over MQTT and stored in-memory. What's wrong?