fuchsia.ui.pointer: striated FIDL libraries for extensibility and API/ABI guarantees

28 views
Skip to first unread message

Jaeheon Yi

unread,
Feb 10, 2021, 10:39:27 PM2/10/21
to api-c...@fuchsia.dev
= Context =
It's a challenge to design a FIDL protocol that (1) allows augmenting an event, (2) have the augmentation scoped to capable clients, (2) avoids mass type and protocol duplication, and (4) retains API and ABI compatibility to existing clients when the event is later extended.

= Proposal =
The fuchsia.ui.pointer proposal is an attempt at providing these properties. There are just two protocols in fuchsia.ui.pointer (touch and mouse), and are intended for regular clients. Clients with the right capability (fuchsia.ui.pointer.augment) can "upgrade" their fuchsia.ui.pointer protocol to also carry extra data that they need (examples are accessibility or Sys UI). The server guarantees that extra data is never sent to regular clients. Furthermore, when a new augmentation need comes along, we can add the capability and its data without impacting both regular clients and existing augmented clients.

These nice properties need some help to express in FIDL. The FIDL compiler enforces a DAG structure on libraries. To accommodate that constraint, regular clients write code against:
(P) fuchsia.ui.pointer ("fup"), defining protocols and just its top-level data types, and
(D) fuchsia.ui.pointer.data ("fup.data"), defining the remaining data types,

and augmented clients write code against
(A) fuchsia.ui.pointer.augment ("fup.augment"), defining the augmentation protocols,
(E) fuchsia.ui.pointer.augment.data ("fup.augment.data"), defining the extra data, which may reuse types in fuchsia.ui.pointer.data. 

These FIDL libraries result in a striated dependency structure:
(topmost) A -(depends on)-> P -(depends on)-> E -(depends on)-> D

= Review Material =
Here is the first version of fup, merged May 14, 2020. This is what we had initially discussed in a past review. As is, it cannot provide "extra data" that is scoped to specific clients. 

This is the next patch of fup, merged Jan 21, 2021. This incorporates the basic idea of augmentation, but is not actually buildable, due to the library cycle between fup and fup.augment. 

I have some fixes in flight that restructure the FIDL libraries. Here are the relevant ones in sequence:

 - bind fup protocols to the Scenic protocol to enable view-scoping properties

 - pull down fup data types into fup.data, as an intermediate step for the next patch

 - introduce one augmentor protocol and data, for mouse

 - introduce another augmentor protocol and data, for touch

= Questions =
Reviewers may notice the tension between nested library names (fup.data, fup.augment, fup.augment.data) and the nesting guidance given in the FIDL Rubric:

On the other hand, these library names follow a natural structure between protocol and data, and follows the "no mutli-word" guidance of the same Rubric:
as well as the "functional roles with meaning" guidance of the Style Guide:

Q1. Is this proposal an appropriate use of nesting for fup.data, fup.augment, and fup.augment.data?

The "fuchsia.hardware" is a namespace broad enough that warrants an extra dot. We don't have that for "fuchsia.ui", so we have awkard names like "fuchsia.ui.pointerinjector". Also, the protocols in "fuchsia.ui" are generally themed around graphics, views, and interactions (touch, keyboard). 

Q2. Can we promote "fuchsia.ui" to generally allow 3 dots in its namespaces?

The "upgrade" pattern, where clients that receive fup.augment.MoreStuffProtocol can have their fup.RegularProtocol decorated with fup.augment.data.MoreStuff, seems new. It stands to replace our kludgy panoply of similar-but-different pointer FIDLs (all in use): fuchsia.ui.scenic.SessionListener, fuchsia.ui.input.accessibility.PointerEventListener, fuchsia.ui.input.PointerCaptureListener, and fuchsia.ui.policy.PointerCaptureListenerHACK. It avoids minting a new pointer FIDL each time we need something new - instead, we may freely mint a new upgrade protocol and associated data, which are controlled tightly, while regular clients remain compatible with new additions to fup.TouchEvent and fup.MouseEvent.

Q3. What do you think about this upgrade pattern?

Thanks,

Jaeheon

Alice Neels

unread,
Feb 11, 2021, 7:15:53 PM2/11/21
to Jaeheon Yi, api-c...@fuchsia.dev
I believe we recently changed the guidance on FIDL namespaces to allow three dots (previously, it was two). What was the rationale there? Does this kind of nesting fit with our policy?

The "fuchsia.ui" namespace is roughly the set of things related to graphics and user input, which are intimately related. It currently contains (almost) all of the APIs that refer to scenic views and operate on them. It's gotten quite large.

-A

--
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.

Dave Schuyler

unread,
Feb 11, 2021, 8:05:30 PM2/11/21
to Alice Neels, Pascal Perez, Jaeheon Yi, api-c...@fuchsia.dev
On Thu, Feb 11, 2021 at 4:15 PM 'Alice Neels' via api-council <api-c...@fuchsia.dev> wrote:
I believe we recently changed the guidance on FIDL namespaces to allow three dots (previously, it was two). What was the rationale there? Does this kind of nesting fit with our policy?

@Pascal Perez is the expert here, but I'm happy to chime in,

I believe there's more to the rational than this, but I really appreciate the ability to avoid running words together and more dots allows that. E.g. if "fuchsia.ui" were to have two clear topics within it: foo and bar; it's better to have "fuchsia.ui.foo" and "fuchsia.ui.bar" rather than "fuchsia.uifoo" or "fuchsia.uibar".

There's still value in having short names. Fewer dots is generally better than more dots. If some API is turning into an and-the-kitchen-sink and something has to give, then we have a choice to prioritize on minimizing dots or on being clear. Allowing more dots allows for prioritizing on being clear. (e.g. easy to see that "fuchsia.ui.foo" is related to UI, not so much with "fuchsia.uifoo".)

P.S. it's also worth considering, in a "fuchsia.ui.foo" case, whether it would be better as "fuchsia.foo". That minimizes dots and could be clearer if foo isn't ui specific. Or in Jaeheon's example, would "fuchsia.pointer" make sense. That might be confusing because of memory pointers or maybe it's not because of the scope/context (why would there be an API for memory pointers).
P.P.S. naming is hard.

Pascal

unread,
Feb 11, 2021, 11:34:59 PM2/11/21
to Jaeheon Yi, api-c...@fuchsia.dev
= Context =
It's a challenge to design a FIDL protocol that (1) allows augmenting an event, (2) have the augmentation scoped to capable clients, (2) avoids mass type and protocol duplication, and (4) retains API and ABI compatibility to existing clients when the event is later extended.

That's true. It is a key deliverable of the FIDL team to design an evolution story for protocols, my hope is that we have something in good shape by mid-year (design wise) with an implementation completed by early 2022.
 
= Proposal =
The fuchsia.ui.pointer proposal is an attempt at providing these properties. There are just two protocols in fuchsia.ui.pointer (touch and mouse), and are intended for regular clients. Clients with the right capability (fuchsia.ui.pointer.augment) can "upgrade" their fuchsia.ui.pointer protocol to also carry extra data that they need (examples are accessibility or Sys UI). The server guarantees that extra data is never sent to regular clients. Furthermore, when a new augmentation need comes along, we can add the capability and its data without impacting both regular clients and existing augmented clients.

To make sure I understand the strategy, let me try to paraphrase what I'm seeing:
  • Some data is shared repeatedly by a server, and represented as some table T (e.g. a TouchEvent)
  • This table T has many fields, but only a base set of fields are filled by the server. For instance, while the table may have 20 fields, only 4 are set by default.
  • A client can request to upgrade, indicating to the server that it is capable (and interested) in receiving more fields.
  • If the server agrees to the upgrade, subsequent data shared by the server will fill in more of the fields of the table T (say maybe 12 out of the 20 for instance, 8 more than previously).
Is this correct?

One piece that I'm missing is why does an upgrade return a new client end, e.g. here?

These nice properties need some help to express in FIDL. The FIDL compiler enforces a DAG structure on libraries. To accommodate that constraint, regular clients write code against:
(P) fuchsia.ui.pointer ("fup"), defining protocols and just its top-level data types, and
(D) fuchsia.ui.pointer.data ("fup.data"), defining the remaining data types,

and augmented clients write code against
(A) fuchsia.ui.pointer.augment ("fup.augment"), defining the augmentation protocols,
(E) fuchsia.ui.pointer.augment.data ("fup.augment.data"), defining the extra data, which may reuse types in fuchsia.ui.pointer.data. 

These FIDL libraries result in a striated dependency structure:
(topmost) A -(depends on)-> P -(depends on)-> E -(depends on)-> D

Why is there a need for more namespaces than `fuchsia.ui.pointer`? I would expect to have everything in the same namespace.
 
= Questions =
Reviewers may notice the tension between nested library names (fup.data, fup.augment, fup.augment.data) and the nesting guidance given in the FIDL Rubric:
On the other hand, these library names follow a natural structure between protocol and data, and follows the "no mutli-word" guidance of the same Rubric:
as well as the "functional roles with meaning" guidance of the Style Guide:

Q1. Is this proposal an appropriate use of nesting for fup.data, fup.augment, and fup.augment.data?

I would start with the general advice about Library structure, specifically "To decide whether to decompose a library into smaller libraries, consider the following questions:"

> Do the customers for the library break down into separate roles that would want to use a subset of the functionality or declarations in the library?

From what you describe above, the breakdown of clients is stages in time (evolution requirements), or different stages of complexity (simple clients vs advanced clients). So there might be a useful breakdown along the complexity axis, but unlikely along the evolution axis since overtime all should gravitate towards the "new".

> Does the library correspond to an industry concept that has a generally understood structure?

Is there an industry precedent for categorising pointer event data that could guide the design here?

> Do many other libraries depend upon the library?

This one question feels the weakest in terms of providing guidance, especially since we hope to provide visibility rules to mitigate this problem. 

Q2. Can we promote "fuchsia.ui" to generally allow 3 dots in its namespaces?


I'm not convinced yet that this reason exists :)

 
The "upgrade" pattern, where clients that receive fup.augment.MoreStuffProtocol can have their fup.RegularProtocol decorated with fup.augment.data.MoreStuff, seems new.

(I'm going to assume my summary above is correct... but if I'm off, then the next section is going to be off too!)

This is one example of protocol negotiation, one technique for protocol evolution. Another example -- on a per request basis, and not per connection basis -- is the fuchsia.io2/Node.GetAttributes method and its NodeAttributesQuery bitset.
 
Q3. What do you think about this upgrade pattern?

I think it's good! We'd even like to help define the companion bits declaration to the "augmentable" table.

PL

Wez

unread,
Feb 12, 2021, 9:16:23 AM2/12/21
to Pascal, Jaeheon Yi, api-c...@fuchsia.dev
Returning to the original problem statement:
 
= Context =
It's a challenge to design a FIDL protocol that (1) allows augmenting an event, (2) have the augmentation scoped to capable clients, (2) avoids mass type and protocol duplication, and (4) retains API and ABI compatibility to existing clients when the event is later extended.

Is this conflating the FIDL specification, which defines the syntax of protocol messages, with the semantics of the protocol that uses it?

For a protocol to introduce additional fields to events, or to replace one field with another, the most flexible tends to be feature opt-in.  Augments to events are defined in the FIDL protocol, but will only actually be sent to clients that explicitly opted-in to them, e.g. via an "init" message when first connecting.

The other common approach is to "version" the protocol, which can take the form of switch to an entirely separate syntax, but more commonly also just defines which messages may be exchanged.

Is there a specific need motivating defining separate protocols for these extra fields?



--

Jaeheon Yi

unread,
Feb 12, 2021, 3:44:39 PM2/12/21
to Wez, Pascal, api-c...@fuchsia.dev
Wez and Pascal, thank you for taking the time! 

On Fri, Feb 12, 2021 at 6:16 AM Wez <w...@google.com> wrote:
Returning to the original problem statement:
 
= Context =
It's a challenge to design a FIDL protocol that (1) allows augmenting an event, (2) have the augmentation scoped to capable clients, (2) avoids mass type and protocol duplication, and (4) retains API and ABI compatibility to existing clients when the event is later extended.

Is this conflating the FIDL specification, which defines the syntax of protocol messages, with the semantics of the protocol that uses it?

For a protocol to introduce additional fields to events, or to replace one field with another, the most flexible tends to be feature opt-in.  Augments to events are defined in the FIDL protocol, but will only actually be sent to clients that explicitly opted-in to them, e.g. via an "init" message when first connecting.

Yes, this proposal aims for opt-in, but guarded via an "upgrade" protocol. 
 

The other common approach is to "version" the protocol, which can take the form of switch to an entirely separate syntax, but more commonly also just defines which messages may be exchanged.

Let's say we clone a new version of fuchsia.ui.pointer.Touch, say fuchsia.ui.pointer.AccessibilityTouch. This is actually our approach today; we have 4 so far: fuchsia.ui.scenic.SessionListener for ordinary clients. fuchsia.ui.input.accessibility.PointerEventListener for accessibility, fuchsia.ui.policy.CapturePointerEventsHACK for Workstation Sys UI, and fuchsia.ui.input.PointerCaptureListener for a Very Important Client. Aside from the namespace mess, this approach leaks "upgrade" types into our graphics protocols.

To gain security properties based on the view tree (detailed below), we'd have to add cloned protocols to the scenic factory function (fuchsia.ui.scenic.Scenic), a routable protocol. But we don't want regular clients to plug in and receive AccessibilityTouch, so we'd also have to clone and route the scenic factory function itself: fuchsia.ui.scenic.ScenicForAccessibility, fuchsia.ui.scenic.ScenicForSysUI, etc. That isn't appealing from a maintenance perspective, as new upgrades shouldn't require defining new graphics protocols. 

It also poses a challenge in keeping these protocols in sync, when they are authored across teams and time. We've already failed in that regard: the existing examples have different data types, namespaces, naming conventions, routing patterns, negotiation patterns, server/client interaction patterns, you name it. 
 

Is there a specific need motivating defining separate protocols for these extra fields?

For example, Accessibility Manager. It should be routed a protocol capability, fup.augment.LocalHitDataAugmentor, to opt in to hit-tested events, and no other component should receive that capability. If LocalHitData needs adjustment, and Accessibility Manager is the sole client (determined by examining CMX files for LocalHitDataAugmentor), we can extend or shrink that table as needed. However, if we have a substantively different accessibility need on a different product (let's make up the Workstation Accessibility Manager), we don't have to coerce the existing LocalHitData into serving those needs. Instead, we can mint a new fup.augment.data.GlobalMouseLocation and route fup.augment.GlobalMouseLocationAugmentor to the WAM. 

A small DX bonus is that the clients don't have to reimplement their code based on augmentation type - it's the same fuchsia.ui.pointer.Mouse (or Touch) protocol, and they just need to look for that extra field. 
 



On Fri, 12 Feb 2021 at 05:35, 'Pascal' via api-council <api-c...@fuchsia.dev> wrote:
= Context =
It's a challenge to design a FIDL protocol that (1) allows augmenting an event, (2) have the augmentation scoped to capable clients, (2) avoids mass type and protocol duplication, and (4) retains API and ABI compatibility to existing clients when the event is later extended.

That's true. It is a key deliverable of the FIDL team to design an evolution story for protocols, my hope is that we have something in good shape by mid-year (design wise) with an implementation completed by early 2022.
 
= Proposal =
The fuchsia.ui.pointer proposal is an attempt at providing these properties. There are just two protocols in fuchsia.ui.pointer (touch and mouse), and are intended for regular clients. Clients with the right capability (fuchsia.ui.pointer.augment) can "upgrade" their fuchsia.ui.pointer protocol to also carry extra data that they need (examples are accessibility or Sys UI). The server guarantees that extra data is never sent to regular clients. Furthermore, when a new augmentation need comes along, we can add the capability and its data without impacting both regular clients and existing augmented clients.

To make sure I understand the strategy, let me try to paraphrase what I'm seeing:
  • Some data is shared repeatedly by a server, and represented as some table T (e.g. a TouchEvent)
  • This table T has many fields, but only a base set of fields are filled by the server. For instance, while the table may have 20 fields, only 4 are set by default.
  • A client can request to upgrade, indicating to the server that it is capable (and interested) in receiving more fields.
  • If the server agrees to the upgrade, subsequent data shared by the server will fill in more of the fields of the table T (say maybe 12 out of the 20 for instance, 8 more than previously).
Is this correct?

Yes.
 

One piece that I'm missing is why does an upgrade return a new client end, e.g. here?

The pointer channel is always tied to the client's scenic session's ViewRef in the Scenic view tree [via the scenic factory function]. The view tree enforces a hierarchical structure, and the pointer channel tie-in enforces security properties within that view tree. That is, even after upgrades, the pointer channel should not gain more powers than granted by its position in the view tree. 

So, given an upgrade request, we need the server to know which pointer channel to upgrade. 
One idea is have the upgrade request send over a ViewRef. But the ViewRef itself cannot be a means of authentication, because it's intended to be freely copied and shared through the system. 
The simplest way seemed to be for the client to hand over the actual channel, which acts as the shared secret betwen client and server. The server then checks that the given channel is already tied to a ViewRef in the view tree, the server gives back that channel to the client, and the server can give the client More Stuff based on the channel's implicit ViewRef.
 

These nice properties need some help to express in FIDL. The FIDL compiler enforces a DAG structure on libraries. To accommodate that constraint, regular clients write code against:
(P) fuchsia.ui.pointer ("fup"), defining protocols and just its top-level data types, and
(D) fuchsia.ui.pointer.data ("fup.data"), defining the remaining data types,

and augmented clients write code against
(A) fuchsia.ui.pointer.augment ("fup.augment"), defining the augmentation protocols,
(E) fuchsia.ui.pointer.augment.data ("fup.augment.data"), defining the extra data, which may reuse types in fuchsia.ui.pointer.data. 

These FIDL libraries result in a striated dependency structure:
(topmost) A -(depends on)-> P -(depends on)-> E -(depends on)-> D

Why is there a need for more namespaces than `fuchsia.ui.pointer`? I would expect to have everything in the same namespace.

If we can disregard cyclic dependency issues, there's just two libraries here:
fuchsia.ui.pointer, for clients with an ordinary role in UI participation
fuchsia.ui.pointer.augment, for clients play a role with extra powers, like accessibility's need to hit test every event, or Sys UI's need to observe screen-dependent global movement. These powers come with clickjacking potential. 

Because the roles are quite different, it seemed appropriate to place them in different libraries - in the same way that fuchsia.ui.pointerinjector is not a capability just any client is expected to have. It also seemed like better DX, in that dumping everything into fuchsia.ui.pointer would force that extra complexity on the developer, to try make sense of everything. 

Access control is provided at protocol granularity, so having the augmentation protocols grouped within fup.augment seems WAI. 

The DAG dependency constraint means we can't actually define the regular { protocols, datatypes } inside fup, and the augmentation { protocols, datatypes } inside fup.augment. The fup.augment protocols depend on the fup protocols, and the fup datatypes embed the fup.augment datatypes. That's what led to the fup.data and fup.augment.data libraries. 

 
= Questions =
Reviewers may notice the tension between nested library names (fup.data, fup.augment, fup.augment.data) and the nesting guidance given in the FIDL Rubric:
On the other hand, these library names follow a natural structure between protocol and data, and follows the "no mutli-word" guidance of the same Rubric:
as well as the "functional roles with meaning" guidance of the Style Guide:

Q1. Is this proposal an appropriate use of nesting for fup.data, fup.augment, and fup.augment.data?

I would start with the general advice about Library structure, specifically "To decide whether to decompose a library into smaller libraries, consider the following questions:"

> Do the customers for the library break down into separate roles that would want to use a subset of the functionality or declarations in the library?

From what you describe above, the breakdown of clients is stages in time (evolution requirements), or different stages of complexity (simple clients vs advanced clients). So there might be a useful breakdown along the complexity axis, but unlikely along the evolution axis since overtime all should gravitate towards the "new".

See role discussion above. I believe it unlikely that regular UI clients (like web, or spinning-square) will later assume a global accessibility management role, or even a Workstation Sys UI role. 

There is plenty of intended room in fuchsia.ui.pointer to accommodate evolutionary growth in touch and mouse. For example, mouse could gain "absolute scrolling" fields, touch could gain "finger width" fields. And simple clients should ignore the advanced stuff, definitely. 

But the roles mentioned above are substantively different, and we expect to accrue distinctive new roles as the Fuchsia platform expands. We also want the ability to retract and delete these role-based capabilities, as we leave behind older products. 
 

> Does the library correspond to an industry concept that has a generally understood structure?

Is there an industry precedent for categorising pointer event data that could guide the design here?

We can't peek inside Apple's a11y, but Android's a11y provides a completely parallel API that defines its own types:
which doesn't really help us here. This proposal might be novel. 


> Do many other libraries depend upon the library?

This one question feels the weakest in terms of providing guidance, especially since we hope to provide visibility rules to mitigate this problem. 

Q2. Can we promote "fuchsia.ui" to generally allow 3 dots in its namespaces?


I'm not convinced yet that this reason exists :)
 
The "upgrade" pattern, where clients that receive fup.augment.MoreStuffProtocol can have their fup.RegularProtocol decorated with fup.augment.data.MoreStuff, seems new.

(I'm going to assume my summary above is correct... but if I'm off, then the next section is going to be off too!)

This is one example of protocol negotiation, one technique for protocol evolution. Another example -- on a per request basis, and not per connection basis -- is the fuchsia.io2/Node.GetAttributes method and its NodeAttributesQuery bitset.

How does the server determine that the caller's demands in NodeAttributesQuery are all valid and grantable? Perhaps there's something in that pattern to leverage here, but if we want to maintain our separation of pointer-upgrades from the general graphical protocol, I don't immediately see a way - do you? 

Alice Neels

unread,
Feb 16, 2021, 8:44:43 PM2/16/21
to Jaeheon Yi, Wez, Pascal, api-c...@fuchsia.dev
Regarding the namespace aspects: can we just put all of the *.data bits into fuchsia.ui.pointer? That feels most intuitive to me but maybe there is a reason. That way in code you get fuchsia.ui.pointer.TouchData, fuchsia.ui.pointer.MouseData, etc. In terms of privilege it's the ability to upgrade a channel that we'd like to guard and not the fact that some clients are capable of receiving extra fields.

Jaeheon Yi

unread,
Feb 16, 2021, 10:45:36 PM2/16/21
to Alice Neels, Wez, Pascal, api-c...@fuchsia.dev
On Tue, Feb 16, 2021 at 5:44 PM Alice Neels <nee...@google.com> wrote:
Regarding the namespace aspects: can we just put all of the *.data bits into fuchsia.ui.pointer? That feels most intuitive to me but maybe there is a reason. That way in code you get fuchsia.ui.pointer.TouchData, fuchsia.ui.pointer.MouseData, etc. In terms of privilege it's the ability to upgrade a channel that we'd like to guard and not the fact that some clients are capable of receiving extra fields.

Yes, but also we get fuchsia.ui.pointer.LocalHitData, fuchsia.ui.pointer.GlobalViewMouseThingy, etc in that namespace. We could certainly merge it all! It feels like a question of priorities and values. 

Does the desire to "avoid nesting too deeply" [1] trump the desire to "help FIDL developers navigate the API surface" [2] and "provide structure to ... scope FIDL decls within FIDL libraries" [3]?

When would we say the latter (structuring on roles) is more important than the former (avoid deep namespacing)? How does API Council proceed here?

Pascal

unread,
Feb 17, 2021, 6:26:51 PM2/17/21
to Jaeheon Yi, Alice Neels, Wez, api-c...@fuchsia.dev
(I owe you a response on the rest -- it will come soon, on my list.) 
 
Regarding the namespace aspects: can we just put all of the *.data bits into fuchsia.ui.pointer? That feels most intuitive to me but maybe there is a reason. That way in code you get fuchsia.ui.pointer.TouchData, fuchsia.ui.pointer.MouseData, etc. In terms of privilege it's the ability to upgrade a channel that we'd like to guard and not the fact that some clients are capable of receiving extra fields.

Yes, but also we get fuchsia.ui.pointer.LocalHitData, fuchsia.ui.pointer.GlobalViewMouseThingy, etc in that namespace. We could certainly merge it all! It feels like a question of priorities and values. 

Does the desire to "avoid nesting too deeply" [1] trump the desire to "help FIDL developers navigate the API surface" [2] and "provide structure to ... scope FIDL decls within FIDL libraries" [3]?

When would we say the latter (structuring on roles) is more important than the former (avoid deep namespacing)? How does API Council proceed here?


Providing crisp yes/no rules is hard, which is why we end up in situations like these. So I think I'd rather answer the specific case, than attempt to refine the general API rubric items which took a while to research and type up.

My hunch is that having all in fuchsia.ui.pointer will lead to a better API:
  • The decomposition axis of what is here or there will likely change overtime. If you anchor today's choice in the library name, you will likely end up in a situation where the decomposition changes... but you are now stuck with yesterday's decomposition. Then it gets messy.
  • Navigating the API surface will not be hurt since the entry point will most likely be through protocols, then navigating to types supporting these protocols.

Wez

unread,
Feb 19, 2021, 10:32:19 AM2/19/21
to Pascal, Jaeheon Yi, Alice Neels, api-c...@fuchsia.dev
I'm having trouble understanding what the problem is that you're trying to solve, and as Pascal points out there is no-one-size-fits-all answer to FIDL design questions in general :)

Could we focus on a specific example?

Pascal

unread,
Feb 19, 2021, 11:02:07 AM2/19/21
to Wez, Jaeheon Yi, Alice Neels, api-c...@fuchsia.dev
Wez, I've set up time to chat about this with Jaehon & Alice, before summarizing here our comments and/or conclusions. Do you want to join?

--

Wez

unread,
Feb 23, 2021, 9:48:26 AM2/23/21
to Pascal, Jaeheon Yi, Alice Neels, api-c...@fuchsia.dev
Thanks Pascal; given the timezone difference probably best to proceed without me
Reply all
Reply to author
Forward
0 new messages