Bikeshed: What is a Service?

[Dave Smith]

Hi Folks. Casting a wide net here since this cuts a couple different layers.

TL;DR: We would like to clarify what it means to be a service. The current documentation uses the term in a few different ways.

For background, here is a sampling of where "services" appear on Fuchsia.dev:

• The glossary definition of Service is "In FIDL, a service groups protocols to describe how one process interacts with another."
• The component framework echoes this definition: "A service is a grouping of named FIDL protocols. Logically-related protocols can be aggregated into a service and routed as a single unit."
• At the system interface level, a different definition appears. From the namespace documentation: "A service is a well-known object that provides an implementation of a FIDL protocol, which can be discovered using the namespace."
• The Fuchsia System Interface echoes this in a few places:
• "For example, the component exposes services for other components using the svc entry in this namespace."
• "For example, the component can access services through the svc entry in this namespace, which conventionally contains services listed by their fully qualified discovery name."

Taken as a whole, you end up with the somewhat circular idea that a service is an implementation of a protocol, which grouped together forms a service.

Are all of these definitions accurate, or are some perhaps outdated and should be removed?

If they are current, two main types seem to emerge (e.g FIDL service vs. service handle). How might we clarify them, or should we rename one of them altogether?

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

[Adam Barth]

Some of the descriptions are outdated.  I think an accurate (if slightly futuristic) definition would be:

A service is a group of named FIDL protocols.

Components implement protocols.

Today, all of our services are singleton groups (i.e., they are groups that contain a single FIDL protocol).  However, we're planning to add support for non-singleton groups as part of making drivers into components.

Adam

--
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/CAHDnuhvntvKdoFysE8Z6wjDpK%2B%2B%2B39JM0i8D65CXr5Fwmo%2BGxQ%40mail.gmail.com.

[Shai Barack]

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

[Dave Smith]

Thanks Adam.

So then the outdated descriptions you are referring to are those at the namespace layer? I believe these are being used to describe the svc/ handles inside a namespace. Should we rename these?

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

[Adam Barth]

On Wed, Jul 14, 2021 at 5:00 PM Dave Smith <smit...@google.com> wrote:

Thanks Adam.

So then the outdated descriptions you are referring to are those at the namespace layer? I believe these are being used to describe the svc/ handles inside a namespace. Should we rename these?

This definition is out-dated because it assumes service is 1-to-1 with protocol.

• At the system interface level, a different definition appears. From the namespace documentation: "A service is a well-known object that provides an implementation of a FIDL protocol, which can be discovered using the namespace."

A more accurate version might be "A service is a directory that contains FIDL protocols.  Implementations of those protocols can be discovered using the namespace."

This definition could be polished up a bit:

• "For example, the component can access services through the svc entry in this namespace, which conventionally contains services listed by their fully qualified discovery name."

Maybe "For example, the component can discover implementations of protocols through the svc entry in this namespace, which conventionally lists protocols by their fully qualified discovery name."

More conceptually, a namespace contains directories.  Some of those directories represent services and contain protocols listed by their fully qualified discovery name.  Components can discover implementations of these protocols using these directories by opening the entries in the directory.

We used to refer to implementations of protocols as services, but now we just call them components.  If we need to be precise about different parts of a component that implement different protocols, we can talk about the "servers" run by the component, much in the same way a computer (analogous to a component) on the network (analogous to the component topology) can run a web server, an email server, and a DNS server (analogous to implementations of different protocols).  On the Internet, these servers are accessible using different port numbers.  In Fuchsia, these servers are accessible using different names in a namespace.

[Dave Smith]

Thanks for all that detail. I took a little time to explore how a component sees it's namespace.

> A more accurate version might be "A service is a directory that contains FIDL protocols. Implementations of those protocols can be discovered using the namespace."

> More conceptually, a namespace contains directories.  Some of those directories represent services and contain protocols listed by their fully qualified discovery name.  Components can discover implementations of these protocols using these directories by opening the entries in the directory.

So if I'm reading all of this correctly, it's not appropriate to uniformly refer to all the contents of `/svc` as "services" (or some other variation like "service handle", "service implementation"), and we should call different `/svc` entries "services" or "protocols" depending on what they are (matching the FIDL definition). This might be what we need to address in the system docs.

Something like `/svc/fuchsia.logger.LogSink` represents a protocol, not a service. The entry is not a directory...it's a file (at least as reported by client code). Using an example from the docs, something like `/svc/fuchsia.network.Provider` represents a service and presumably it would be a directory containing "instance" subdirectories (e.g. `default`) with the individual protocol file entries. This seems to be true for either an outgoing directory or a namespace. Does that seem accurate?

The question remains on the best way for us to generally refer to the various `/svc` nodes in an outgoing directory or namespace. Are they handles? endpoints? Perhaps it depends on which end we are referring to?

Floating some examples ideas:

`/svc/fuchsia.logger.LogSink` in a component's outgoing directory is a "protocol implementation"
`/svc/fuchsia.logger.LogSink` in a component's namespace is a "protocol handle"
`/svc/fuchsia.network.Provider` in a component's outgoing directory is a "service implementation"
`/svc/fuchsia.network.Provider` in a component's namespace is a "service handle"

Thoughts?

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

[Gary Bressler]

I recommend:

`/svc/fuchsia.logger.LogSink` in a component's {outgoing directory, namespace} is a {protocol, service, ...}

It's possible to add more qualifiers to be more precise, but at the expense of readability. The underlying VFS representation is a "service node" (for, confusingly, both protocols and services) or a "directory node", but those details aren't relevant to users most of the time.

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

[Dave Smith]

>  The underlying VFS representation is a "service node" (for, confusingly, both protocols and services) or a "directory node", but those details aren't relevant to users most of the time.

Did you mean that both the `/svc/fuchsia.logger.LogSink` and `/svc/fuchsia.network.Provider` examples I gave would be "service nodes"? Or that the protocol was a "service node" and the service was a "directory node"?

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

[Gary Bressler]

Yes, I got it wrong. A service would indeed be represented by a directory node. Which is probably even more confusing :-)

[Adam Barth]

We should change the name of the underlying VFS node.  The terminology we're using there reflects the older design of the system before we started using the concept of a service to mean a group (aka Directory) of protocols.

Adam

[Dave Smith]

Thanks for all the feedback here, folks.

I've posted fxr/556408 to wrap up the discussion here and clean up the docs. PTAL and let me know if anything needs to be adjusted.

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