Could 'absolute' and 'relative' monikers be merged?

[Gary Bressler]

Continuing a discussion on CF chat about monikers where we made a couple observations:

• It doesn't seem like we have any APIs that use the 'upward' part of a relative moniker (need to confirm though).
• An absolute moniker can be thought of as a relative moniker 'relative to root'.

Instead, what if every moniker looked like this:

path/to/my/component

The original motivating use case for relative monikers was client identity, which still hasn't emerged in practice and considering the weak stability properties of monikers it seems unclear if that's even the right approach. 

[Hunter Freyer]

I hypothesize that in many or most of the situations where we have a problem with folks assuming moniker stability, it wouldn't actually be a problem if they were using the moniker relative to some "sandbox" the user is working in. For instance: if diagnostics for product components were indexed by their moniker relative to the session component, does that fix problems? Or for tests, the monikers could be relative to a component that represents the "test environment".

Anyone have any data on whether that's an accurate hunch or not?

Hunter

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "component-framework-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to component-framewo...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK1yh2kWSAJHC-6Li4gg43p2p7cW6Wh1-tDgYvBKYTRh06iRoA%40mail.gmail.com.

[Aaron Wood]

I really like the idea of the monikers being relative to known, but separately stated, parents.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAMkOBft_tEwd3nuAJT1-jDBh-qVhctUnZN4zKDjQ1W17PX3Trg%40mail.gmail.com.

[Gary Bressler]

That might be ok as long as the diagnostics rules and components are in the same petal and you remember to update them atomically. But even a single product may be assembled from components from different petals, which have their own internal structure.

For the imagined use case where the client gets a stable, obfuscated identifier the idea is that the token may be persisted to memory or storage, which can't be 'fixed' by updating the source.

[Gabe Schine]

Hunter: I'm generally supportive of merging the two concepts.

I also like the idea of using monikers as relative to some known point in the topology, where relative to root is the only option today. Moniker stability is a problem when monikers become part of an implicit API contract, which seems to happen when the domain owner of one system needs to know monikers within another system in order to reference components in their system. Because that was a mouthful: a good example you already alluded to is product architects wanting to reference a component in the "session system" needing to know internals of the "platform system" in order to say "moniker A relative to the session".

An aside: for developer tooling, we may want to consider friendly human-readable aliases for the stable machine-readable identifiers that we already assign.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CAK1yh2kaExLzhV5zC9RCvygjLBwisJOguqCCSZf5gksYok2xfQ%40mail.gmail.com.

--

Gabe Schine

Software Engineer / Manager

🔵 Blue Dot Ally

go/thatguy-readme

go/where-is-thatguy

[Miguel Flores]

On Mon, Sep 20, 2021 at 4:12 PM 'Gabe Schine' via component-framework-dev <component-f...@fuchsia.dev> wrote:

Hunter: I'm generally supportive of merging the two concepts.

I also like the idea of using monikers as relative to some known point in the topology, where relative to root is the only option today.

There's at least one use case today where we use monikers relative to something else than the root realm: "moniker relative to the test root".

This enables tests to request inspect and logs for components under the test without having to type the whole path from the root + their unique test id.

So instead of a test asking for inspect of `core/test_manager/tests:test-1234/test_root/some_component`, it asks for `some_component` and as a plus, the test has no visibility into anything outside `core/test_manager/tests:test-1234/test_root/`.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CACNy_LS2E8%2ByhPLoVt%2BmQ7cfDhkW1miEXhZhR%3DWTMAGjgkzmQw%40mail.gmail.com.

[Aaron Wood]

I think this is near to some other concepts, where we know that we have "known points" in the topology where configuration is required, or things get complicated:

- session component

- driver components (when they exist, need to live somewhere)

- SWD has two components that are mutually exclusive implementations of the same "component", they may or may not have the same moniker.

The configurable resolver RFC draft that I put up a while ago is touching on this from the other side, but I think they're different sides of the same coin:  We have these points in the topology that are meaningful, and have reason to be called out specifically, either for configuration, for setting which component should be there, or just for being able to refer to it, since it's "an important thing" when looking at the platform externally.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CABPw2N3AtjenNfu-chMFeEVdfjabiAjkMZU7tz%2B6gMMDDUDnoA%40mail.gmail.com.