A Few Questions From The Components Documentation

[Caslyn Tonelli]

Hello,

My name is Caslyn, I'll be joining the components framework team on Monday (nice to meet you). I've been reading the documentation to help build a mental model of things and a few questions/ponderings came up. Would anyone be able to offer any insight or information?

_component lifecycle_
I've read that components can stop themselves when their program exits (I also imagine crashing or from a sigkill), but how/when is a component destroyed or purged? 

_collections_
How are child components dynamically created and added to a collection at runtime? What mechanism prompts the component creation and how is that communicated to the component manager?

_random questions_
Is offering/exposing a capability conditionally something that a component would ever need or want to do? 

I think that's it for the time being - but please let me know if I can clarify anything. Any info is appreciated!

Thank you! 
Caslyn

[Suraj Malhotra]

Hi Caslyn,

I've responded inline. I don't actually work on the component framework, so apologies if I might have gotten some of it a bit wrong 😅.

On Thu, Oct 21, 2021 at 7:18 PM Caslyn Tonelli <caslyn....@gmail.com> wrote:

Hello,

My name is Caslyn, I'll be joining the components framework team on Monday (nice to meet you). I've been reading the documentation to help build a mental model of things and a few questions/ponderings came up. Would anyone be able to offer any insight or information?

Awesome, I look forward to future interactions :)

 

_component lifecycle_
I've read that components can stop themselves when their program exits (I also imagine crashing or from a sigkill), but how/when is a component destroyed or purged? 

Components in the static topology are never destroyed or created, they are only started and stopped. If the component is spawned in a collection, the lifetime is dynamic and the entity who spawned the component via CreateChild may call DestroyChild to destroy it. Do note that almost all uses of spawning components in a collection today spawn them as "single-run" in which case they are started on creation (well really on opening the exposed dir) and destroyed on stop.

 

_collections_
How are child components dynamically created and added to a collection at runtime? What mechanism prompts the component creation and how is that communicated to the component manager?

The fuchsia.sys2.Realm protocol used for this purpose. It's routed from the framework to the component creating the components. There are a variety of reasons that an entity may choose to create the component in a collection, such as a developer trying to run a test via fx test, a driver being launched in response to a bind event, or a command being executed in the starnix shell.

 

_random questions_
Is offering/exposing a capability conditionally something that a component would ever need or want to do? 

At the component framework level, this doesn't happen (to my knowledge), however it's possible to have a capability that "vends" sub-capabilities based on some conditions/policy. For instance, you might have a protocol which lets you request ownership of a usb device (which is it's own capability), but if the policy for the component vending that access only allows the first person who asks for it to gain access, then subsequent requests for that capability will fail. Again, that sort of thing would be implemented *above* the component framework.

 

I think that's it for the time being - but please let me know if I can clarify anything. Any info is appreciated!

Thank you! 
Caslyn

--
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/CAKW2%3Dg84m8x7DCZ9FeCze9W7oJfyNmcn_vv_LK9m5XnfXwBByQ%40mail.gmail.com.

[Caslyn Tonelli]

Ah, thanks for that information Suraj. That helps clear things up. I missed the use of the Realm protocol to create/manage collections in the docs, and to be truthful I mistook a Realm as simply a concept to describe relationships, until you pointed out the actual protocol.

[Derek Gonyeo]

One nit on Suraj's answer: many of the components launched in collections have the "transient" durability, which means these components can stop and start again without being destroyed (unlike with the single-run components he mentioned, as those are destroyed on stop).

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

[Justin Mattson]

In terms of conditionally offering something, one small step in that direction is RFC-107, which allows for some dynamic control over children in a collection. I think this is now implemented.

Cheers,

Justin

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

[Caslyn Tonelli]

Thanks Derek and Justin for the additional information! It certainly helps get a bit more acquainted with component behaviors. Excited to be on the team :)