"Outgoing namespace" vs "outgoing directory"?

[Gabe Schine]

These two terms seem to be used interchangeably. Examples: 

• Outgoing namespace: https://fuchsia.dev/fuchsia-src/concepts/components/v2/hub?hl=en#hub-exec-out
• Outgoing directory: https://fuchsia.dev/fuchsia-src/concepts/system/abi/system?hl=en#outgoing_directory

Let's, for now, table the relationship between these terms and the "exposed directory"[1], which one could argue deserves another discussion.

Some open discussion: 

• An incoming namespace is represented as a list of <path prefix>, <directory handle> pairs, which is used to synthesize what looks like a single directory hierarchy to the component at runtime.
• An outgoing directory / outgoing namespace is an analog: it contains entries that allow the component to synthesize capability handles for others when requested of that component.

The incoming namespace / outgoing directorispace are paired in this way. I propose we rally around one or the other term.

Arguments for "outgoing namespace":

• It makes it clear that it's the analog of "incoming namespace", and in most ways, it is.

Arguments for "outgoing directory":

• It's a single handle, not a list of prefix->handle, like namespace is. Due to this discrepancy in construction, it deserves a different name.

Are there other thoughts? Did I get this wrong and we're about to enter into an "educational moment"?

Gabe

[1] My understanding: a synthesized directory, served by `component_manager` itself, that contains all of the routes in a specific component's .CML with a target of "parent" (== all of the "expose" declarations), regardless of where they are routed from.

--

Gabe Schine

Software Engineer / Manager

🔵 Blue Dot Ally

go/thatguy-readme

go/where-is-thatguy

[Dave Smith]

Also related: https://fuchsia.dev/fuchsia-src/concepts/process/namespaces?hl=en#components

My reading of the above is that the "incoming namespace" is actually part of the Fuchsia namespace for the component, while the outgoing elements are not?

Or are both incoming and outgoing part of the broader "Fuchsia namespace" for a component?

Dave Smith | Developer Relations | smit...@google.com | @devunwired

[Hunter Freyer]

Slight preference for "namespace". I think of fuchsia.io as the transport we use to route capabilities around, not as intrinsic to the model itself. In other words, someday a certain kind of runner could publish capabilities via some mechanism other than a fuchsia.io.Directory, in which case "namespace" would be less confusing.

--
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/CACNy_LQWJKs1T84ERpno-dBNiXPnj%3DyrW5vq3XWxr%3DGTfQWcJw%40mail.gmail.com.

[Gabe Schine]

"outgoing namespace" is new to me: it wasn't until today that I realized it was being used in documentation.

"Fuchsia namespace" was, to me, equivalent to the incoming namespace. Here's a quote from https://fuchsia.dev/fuchsia-src/concepts/system/abi/system?hl=en:

"The fuchsia.io FIDL library provides protocols for file and directory operations. Fuchsia uses the fuchsia.io protocols to provide a namespace to components through which components can access system services and resources. The names in these namespaces follow certain conventions, which are part of the system ABI. See namespaces for more details."

At the process level, the "outgoing thing" is identified by this numbered handle: https://osscs.corp.google.com/fuchsia/fuchsia/+/master:zircon/system/public/zircon/processargs.h;l=149?q=PA_DIRECTORY_REQUEST&ss=fuchsia

FWIW it's doesn't mention "namespace". Here's the glossary definition:

"A namespace is the composite hierarchy of files, directories, sockets, services, and other named objects offered to components by their environment."

So, we're pretty inconsistent.

[Seth Ladd]

cc +Guinevere de la Mare 

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

[Dave Smith]

The description of "incoming namespace" on the hub page also makes it sound like somewhat of a partial, insofar as it seems to mainly cover content sourced by capabilities (protocols, directories):

https://fuchsia.dev/fuchsia-src/concepts/components/v2/hub?hl=en#hub-exec-in

The Fuchsia namespace would also include bits from the package (maybe that's the only difference?)

Dave Smith | Developer Relations | smit...@google.com | @devunwired

[Gabe Schine]

Dave - yes, it's incomplete. I think it points to the need for a dedicated section in the docs that describes how component_manager constructs the incoming namespace for a component.

[Justin Mattson]

I've long been frustrated by the incongruity of "incoming namespace" and "outgoing directory". Perhaps because I lack knowledge but the incoming namespace is, for all intents and purposes, accessed like a directory. The fact that the implementation behind it is rather unlike a traditional directory seems to me an implementation detail that is relevant to implementers, but doesn't provide value to component developers.

Additionally frustrating is that in and out are different types effectively. If a component has an incoming namespace, why can't it have an outgoing namespace?

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

[Dave Smith]

Yes, and along those lines I think it might be difficult because it's not clear what the common container is.

I previously considered that incoming / outgoing were "directories in" (and therefore "pieces of") the component's Fuchsia namespace. However, the stated definition of a namespace being things "offered to components by their environment" seems to exclude outgoing anything. List also seems to be practically true, because if I list the contents of my namespace I can't see any "outgoing" things.

So is the environment the thing that contains the (incoming) namespace and the outgoing (directory)? That term seems to have a slightly different definition in CF.

Dave Smith | Developer Relations | smit...@google.com | @devunwired

[Adam Barth]

"Environment" in CFv1 was what we now call "parent component" in CFv2.  The sentence isn't exactly correct in CFv2 if you replace "environment" with "parent component."  It's probably more accurate to say the parent component offers capabilities that the component framework uses to create the incoming namespace for the component.

Adam

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

[Justin Mattson]

There is no container for these things in the conventional sense. What the component gets is bounded by the ComponentStartInfo. The main things we're talking about here are ComponentStartInfo::ns and ComponentStartInfo::outgoing_dir.

How these actually get presented to the execution environment of the component is up to the runner. For ELF Runner the namespace handle gets passed in to the process and then the FDIO library is used to interact with the namespace and open things. Similarly there are particular calls to expose things through the outgoing directory.

Other runners would be free to expose these concepts in whatever way made sense to the code they were going to run.

[Gary Bressler]

I think "outgoing namespace" is a misnomer because a namespace has a technical definition (list of name -> handle pairs) that a directory does not meet. I don't think using a namespace is exactly like using a directory; fdio provides specific functions for connecting to services in the namespace.

The symmetry is obvious though, so informally I don't think it's a big problem to call it a namespace. But in our documentation I think we should prefer the more accurate terminology.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/component-framework-dev/CA%2BX8dX_XK7fUZvYZ_xtz22ydj%3Dsy_CPkQHBRQNwGsP-nsy%3DmGw%40mail.gmail.com.

[Dave Smith]

> There is no container for these things in the conventional sense. What the component gets is bounded by the ComponentStartInfo. The main things we're talking about here are ComponentStartInfo::ns and ComponentStartInfo::outgoing_dir.

Thanks, this is helpful. Based on that, I wonder if the appropriate change is to drop the "incoming"...a component simply has a namespace (which is the same as it's Fuchsia namespace it seems according to the code comments) plus some additional directories that it serves (outgoing, exposed, runtime)?

It would seem that if an "outgoing namespace" were to exist (logical or otherwise), it would actually contain all of these served directories/handles? If so, should we explain it that way?

Dave Smith | Developer Relations | smit...@google.com | @devunwired

[Gary Bressler]

Yes, I think the 'incoming' is technically redundant, it seems fine to strip from documentation. If we one day turn the outgoing dir into a namespace-like thing we may need that qualifier, but that's the future.

The outgoing dir contains (or should contain) handles for all the capabilities declared by a component. Conceptually it's a lot like the namespace, but the underlying structure is different: they are stored under a single FS rather than a collection of handles.

[Dave Smith]

Sorry, I realized that the last comment got separated from the context. What I was asking was essentially whether describing it like this made sense:

Outgoing Namespace = Outgoing Directory + Exposed Directory + Runtime Directory

If that were valid, then perhaps the directional distinctions made sense to separate the set of things "provided to" a component vs. those "provided by" it.

If not, and a namespace should remain (by definition) the collection of things provided to a component, dropping "incoming" may be the most helpful change.

Dave Smith | Developer Relations | smit...@google.com | @devunwired

[Fady Samuel]

I think that's more confusing. There is (necessarily) overlap between the Outgoing and Exposed directories. The Runtime directory is populated by the runner and not the component itself.

Fady

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

[Dave Smith]

Thanks for the feedback here everyone!

I've created fxr/554661 to update the related glossary definitions and references based on this thread. Please feel free to leave any additional comments there.

Dave Smith | Developer Relations | smit...@google.com | @devunwired