CINXE.COM

<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link rel="stylesheet" href="/css/layout.css?1718759055581"> <link rel="stylesheet" href="/css/nav.css?1718759055581"> <link rel="stylesheet" href="/css/style.css?1718759055581"> <link rel="stylesheet" href="/css/prismjs@1.24-themes-prism.css"> <title>IPLD ♦ ADL Signalling</title> </head> <body> <header> <div class="sidebar-button" onclick="document.getElementById('sidebar').classList.toggle('sidebar-open')"> <svg xmlns="http://www.w3.org/2000/svg" aria-hidden="true" role="img" viewBox="0 0 448 512" class="icon"> <path fill="currentColor" d="M436 124H12c-6.627 0-12-5.373-12-12V80c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12zm0 160H12c-6.627 0-12-5.373-12-12v-32c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12zm0 160H12c-6.627 0-12-5.373-12-12v-32c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12z"></path> </svg> </div> <a href="/" class="logo">IPLD</a> <aside id=breadcrumbs> <ul> <li><a href="/docs">docs</a></li> <li><a href="/docs/advanced-data-layouts">advanced-data-layouts</a></li> <li><a href="/docs/advanced-data-layouts/signalling/">signalling</a></li> </ul> </aside> </header> <aside id=sidebar> <nav> <ul> <li> <a href="/docs/">Docs</a><ul> <li> <a href="/docs/intro/">Intro</a><ul> <li> <a href="/docs/intro/hello-world/">Hello, World</a></li> <li> <a href="/docs/intro/primer/">The Brief Primer</a></li> <li> <a href="/docs/intro/ecosystem/">InterPlanetary Ecosystem Overview</a></li> <li> <a href="/docs/intro/community/">Finding Community</a></li></ul></li> <li> <a href="/docs/motivation/">Motivation</a><ul> <li> <a href="/docs/motivation/benefits-of-content-addressing/">Benefits of Content Addressing</a></li> <li> <a href="/docs/motivation/data-to-data-structures/">From Data to Data Structures</a></li></ul></li> <li> <a href="/docs/codecs/">Codecs</a><ul> <li> <a href="/docs/codecs/known/">Known Codecs</a><ul> <li> <a href="/docs/codecs/known/dag-cbor/">DAG-CBOR</a></li> <li> <a href="/docs/codecs/known/dag-json/">DAG-JSON</a></li> <li> <a href="/docs/codecs/known/dag-pb/">DAG-PB</a></li></ul></li></ul></li> <li> <a href="/docs/data-model/">Data Model</a><ul> <li> <a href="/docs/data-model/node/">Nodes</a></li> <li> <a href="/docs/data-model/kinds/">Kinds</a></li> <li> <a href="/docs/data-model/pathing/">Pathing</a></li> <li> <a href="/docs/data-model/traversal/">Traversal</a></li></ul></li> <li> <a href="/docs/advanced-data-layouts/">Advanced Data Layouts</a><ul> <li> <a href="/docs/advanced-data-layouts/intro/">Intro to ADLs</a></li> <li> <a href="/docs/advanced-data-layouts/naming/">ADL Naming</a></li> <li class="active-page"> <a href="/docs/advanced-data-layouts/signalling/">Signalling ADLs</a></li> <li> <a href="/docs/advanced-data-layouts/dynamic-loading/">Dynamic Loading</a></li> <li> <a href="/docs/advanced-data-layouts/known/">Known ADLs</a></li></ul></li> <li> <a href="/docs/schemas/">Schemas</a><ul> <li> <a href="/docs/schemas/intro/">Introduction</a><ul> <li> <a href="/docs/schemas/intro/compare/">compare</a></li> <li> <a href="/docs/schemas/intro/goals/">Goals</a></li> <li> <a href="/docs/schemas/intro/feature-summary/">Feature Summary</a></li></ul></li> <li> <a href="/docs/schemas/features/">Features</a><ul> <li> <a href="/docs/schemas/features/typekinds/">Type Kinds</a></li> <li> <a href="/docs/schemas/features/representation-strategies/">Representation Strategies</a></li> <li> <a href="/docs/schemas/features/links/">Links</a></li> <li> <a href="/docs/schemas/features/indicating-adls/">Using ADLs in Schemas</a></li></ul></li> <li> <a href="/docs/schemas/using/">Using Wisely</a><ul> <li> <a href="/docs/schemas/using/authoring-guide/">Authoring Guide</a></li> <li> <a href="/docs/schemas/using/migrations/">Migrations</a></li></ul></li></ul></li> <li> <a href="/docs/synthesis/">Synthesis</a><ul> <li> <a href="/docs/synthesis/gtd/">Getting Things Done</a></li> <li> <a href="/docs/synthesis/building-in-alignment/">Building in Alignment</a></li> <li> <a href="/docs/synthesis/how-ipfs-web-gateways-work/">How IPFS Web Gateways Work</a></li> <li> <a href="/docs/synthesis/encryption/">Working With Encryption</a></li></ul></li></ul></li> <li> <a href="/specs/">Specs</a><ul> <li> <a href="/specs/about/">About the Specifications</a></li> <li> <a href="/specs/codecs/">Codecs</a><ul> <li> <a href="/specs/codecs/dag-cbor/">DAG-CBOR</a><ul> <li> <a href="/specs/codecs/dag-cbor/fixtures/">DAG-CBOR Test Fixtures</a><ul> <li> <a href="/specs/codecs/dag-cbor/fixtures/cross-codec/">cross-codec</a></li></ul></li> <li> <a href="/specs/codecs/dag-cbor/spec/">Spec</a></li></ul></li> <li> <a href="/specs/codecs/dag-cosmos/">DAG-COSMOS</a><ul> <li> <a href="/specs/codecs/dag-cosmos/basic_types/">basic_types</a></li> <li> <a href="/specs/codecs/dag-cosmos/cosmos_state/">cosmos_state</a></li> <li> <a href="/specs/codecs/dag-cosmos/crypto_types/">crypto_types</a></li> <li> <a href="/specs/codecs/dag-cosmos/tendermint_chain/">tendermint_chain</a></li> <li> <a href="/specs/codecs/dag-cosmos/typed_protobuf/">typed_protobuf</a></li></ul></li> <li> <a href="/specs/codecs/dag-eth/">DAG-ETH</a><ul> <li> <a href="/specs/codecs/dag-eth/basic_types/">basic_types</a></li> <li> <a href="/specs/codecs/dag-eth/chain/">chain</a></li> <li> <a href="/specs/codecs/dag-eth/convenience_types/">convenience_types</a></li> <li> <a href="/specs/codecs/dag-eth/state/">state</a></li></ul></li> <li> <a href="/specs/codecs/dag-jose/">DAG-JOSE</a><ul> <li> <a href="/specs/codecs/dag-jose/fixtures/">fixtures</a></li> <li> <a href="/specs/codecs/dag-jose/spec/">Spec</a></li></ul></li> <li> <a href="/specs/codecs/dag-json/">DAG-JSON</a><ul> <li> <a href="/specs/codecs/dag-json/fixtures/">DAG-JSON Test Fixtures</a><ul> <li> <a href="/specs/codecs/dag-json/fixtures/cross-codec/">cross-codec</a></li></ul></li> <li> <a href="/specs/codecs/dag-json/spec/">Spec</a></li></ul></li> <li> <a href="/specs/codecs/dag-pb/">DAG-PB</a><ul> <li> <a href="/specs/codecs/dag-pb/fixtures/">DAG-PB Test Fixtures</a><ul> <li> <a href="/specs/codecs/dag-pb/fixtures/cross-codec/">cross-codec</a></li></ul></li> <li> <a href="/specs/codecs/dag-pb/spec/">Spec</a></li></ul></li></ul></li> <li> <a href="/specs/advanced-data-layouts/">Advanced Data Layouts</a><ul> <li> <a href="/specs/advanced-data-layouts/fbl/">FBL ADL</a><ul> <li> <a href="/specs/advanced-data-layouts/fbl/spec/">spec</a></li></ul></li> <li> <a href="/specs/advanced-data-layouts/hamt/">HAMT ADL</a><ul> <li> <a href="/specs/advanced-data-layouts/hamt/fixture/">HashMap (HAMT) Test Fixtures</a><ul> <li> <a href="/specs/advanced-data-layouts/hamt/fixture/alice-words/">alice-words</a></li></ul></li> <li> <a href="/specs/advanced-data-layouts/hamt/spec/">spec</a></li></ul></li></ul></li> <li> <a href="/specs/schemas/">Schemas</a><ul> <li> <a href="/specs/schemas/prelude/">prelude</a></li></ul></li> <li> <a href="/specs/transport/">Transports</a><ul> <li> <a href="/specs/transport/car/">CAR</a><ul> <li> <a href="/specs/transport/car/carv1/">CARv1 Specification</a></li> <li> <a href="/specs/transport/car/carv2/">CARv2 Specification</a></li> <li> <a href="/specs/transport/car/fixture/">CAR Test Fixtures</a><ul> <li> <a href="/specs/transport/car/fixture/carv1-basic/">carv1-basic</a></li> <li> <a href="/specs/transport/car/fixture/carv2-basic/">carv2-basic</a></li></ul></li></ul></li> <li> <a href="/specs/transport/graphsync/">Graphsync</a><ul> <li> <a href="/specs/transport/graphsync/known_extensions/">known_extensions</a></li></ul></li> <li> <a href="/specs/transport/trustless-pathing/">Trustless Pathing</a><ul> <li> <a href="/specs/transport/trustless-pathing/fixtures/">Trustless Pathing Fixtures</a><ul> <li> <a href="/specs/transport/trustless-pathing/fixtures/unixfs_20m_variety/">unixfs_20m_variety</a></li></ul></li></ul></li></ul></li> <li> <a href="/specs/selectors/">Selectors</a><ul> <li> <a href="/specs/selectors/fixtures/">fixtures</a><ul> <li> <a href="/specs/selectors/fixtures/selector-fixtures-1/">selector-fixtures-1</a></li> <li> <a href="/specs/selectors/fixtures/selector-fixtures-adl/">selector-fixtures-adl</a></li> <li> <a href="/specs/selectors/fixtures/selector-fixtures-recursion/">selector-fixtures-recursion</a></li></ul></li></ul></li> <li> <a href="/specs/patch/">Patch</a><ul> <li> <a href="/specs/patch/fixtures/">IPLD Patch Test Fixtures</a><ul> <li> <a href="/specs/patch/fixtures/fixtures-1/">fixtures-1</a></li></ul></li></ul></li></ul></li> <li> <a href="/libraries/">Libraries</a><ul> <li> <a href="/libraries/golang/">Golang</a></li> <li> <a href="/libraries/javascript/">JavaScript</a></li> <li> <a href="/libraries/python/">Python</a></li> <li> <a href="/libraries/rust/">Rust</a></li></ul></li> <li> <a href="/design/">Design</a><ul> <li> <a href="/design/objectives/">Objectives</a></li> <li> <a href="/design/concepts/">Concepts</a><ul> <li> <a href="/design/concepts/type-theory-glossary/">type-theory-glossary</a></li></ul></li> <li> <a href="/design/libraries/">Libraries</a><ul> <li> <a href="/design/libraries/nodes-and-kinds/">nodes-and-kinds</a></li></ul></li> <li> <a href="/design/tricky-choices/">Tricky Choices</a><ul> <li> <a href="/design/tricky-choices/dag-pb-forms-impl-and-use/">dag-pb-forms-impl-and-use</a></li> <li> <a href="/design/tricky-choices/map-key-domain/">map-key-domain</a></li> <li> <a href="/design/tricky-choices/numeric-domain/">numeric-domain</a></li> <li> <a href="/design/tricky-choices/ordering/">ordering</a></li> <li> <a href="/design/tricky-choices/string-domain/">string-domain</a></li></ul></li> <li> <a href="/design/open-research/">Open Research</a><ul> <li> <a href="/design/open-research/ADL-autoexecution/">ADL autoexecution</a></li></ul></li></ul></li> <li> <a href="/tools/">Tools</a></li> <li> <a href="/glossary/">Glossary</a></li> <li> <a href="/media/">Media</a></li> <li> <a href="/FAQ/">FAQ</a></li></ul> </nav> </aside> <main> <div class=content> <h1>Advanced Data Layout Signalling</h1> <p><a href="..">Advanced Data Layouts</a> are a feature of IPLD which gives us "lenses" to view data in another way.</p> <p>This page is about answering the question: "How do I tell IPLD when and where to apply an ADL while reading data?"</p> <div class="callout callout-info"> <p>Read <a href="../intro/">the intro page about ADLs</a> first, if you haven't already. The broader concept of ADLs, and why they need a concept of "signalling", is introduced there.</p> </div> <h2 id="always-optional" tabindex="-1"><a class="header-anchor" href="#always-optional">Always Optional</a></h2> <p>An important thing to remember about ADLs is that the use of them is <em>always optional</em>.</p> <p>Data can be read with an ADL -- or without. <a href="/docs/data-model/pathing/">Pathing</a> over the data works differently depending on whether an ADL is engaged or not, but the data can <em>be</em> pathed over, in some way, either way. If you don't want to use an ADL to read data, it's still legible -- just as the <a href="/docs/data-model/">plain data model</a> content, as a <a href="/glossary#codec">codec</a> already gave it to you.</p> <p>And different ADLs can be applied to the same data, resulting in different views! It's like putting on a different pair of glasses -- maybe some do a better job of making the data legible than others!</p> <p>Therefore, signalling mechanisms -- things that tell you, or tell an IPLD library, when to engage an ADL, and <a href="../naming/">what ADL to engage</a> -- are <em>also</em> optional, and by nature, advisory.</p> <p>We'll talk about some of the various mechanisms a system can use in the next sections.</p> <h2 id="signalling-mechanisms" tabindex="-1"><a class="header-anchor" href="#signalling-mechanisms">Signalling Mechanisms</a></h2> <p>There are many ways to approach solving the signalling problem.</p> <p>In brief:</p> <ul> <li><a href="#code-directly-without-signalling">Code directly, without signalling</a></li> <li><a href="#signalling-with-schemas">Signalling with Schemas</a></li> <li><a href="#signalling-with-selectors">Signalling with Selectors</a></li> <li><a href="#signal-suites">Signal suites</a></li> <li><a href="#signalling-in-band">Signalling in-band</a></li> <li>or there may be <a href="#other-declarative-signalling">other, new declarative signalling systems</a> as yet undeveloped.</li> </ul> <p>Some of these are concrete, standardized protocol solutions. Some are more like design patterns. (We'll always advise trying to use the more standardized solutions, but we can't stop systems in the wild from wiring things as they please, so we try to at least provide terminology for describing those less standardized approaches, too.)</p> <p>You can also <a href="#combining-signalling-mechanisms">combine signalling mechanisms</a>.</p> <p>Let's discuss each of these in a short section. (As a rule of thumb, when you're designing a protocol -- you should probably be able to link to one of these sections and say "this: this is what this protocol is doing"!)</p> <h3 id="code-directly-without-signalling" tabindex="-1"><a class="header-anchor" href="#code-directly-without-signalling">Code directly, without signalling</a></h3> <p>The most direct way to engage with the signalling problem is to simply <em>do things</em>, using application code, and directly calling library functions.</p> <p>This approach is arguably not a signalling mechanism at all. When we talk about direct action in code, we mean there isn't really any convention at all in play; or if it is, it's "implementation defined" by the code you have written. However, even if it isn't "signalling", it's worth remembering that this it's a practical reality: applications can <em>always</em> be written this way. This is just the most degenerate, least useful, least standardized way of signalling.</p> <div class="callout callout-tip"> <p>We encourage using one of the other mechanisms of signalling when working the IPLD ecosystem, because the more declarative and standard of a signalling system you use, the easier it will make it for others to interact with your data, and the more that IPLD application and library developers can help you.</p> </div> <p>Some IPLD libraries do provide feature hooks to help you do this. For example, in the golang implementation, a <a href="https://pkg.go.dev/github.com/ipld/go-ipld-prime/linking#NodeReifier">NodeReifer callback</a> provides a place to hook custom code into the flow for loading data, which allows it to be used throughout other library behaviors like traversals.</p> <p>But again, this is probably pretty disappointing, if you were looking for standardization. So let's continue on to the next sections, which will describe other approaches for more declarative and more standardized mechanisms of signalling.</p> <h3 id="signalling-with-schemas" tabindex="-1"><a class="header-anchor" href="#signalling-with-schemas">Signalling with Schemas</a></h3> <p>IPLD Schemas allow you to name "types" in data, and also allow you to declare that you expect some data to processed by an ADL.</p> <p>For example, the Schema DSL for this looks something like the following:</p> <pre class="language-ipldsch"><code class="language-ipldsch"><span class="token typedef"><span class="token keyword">advanced</span> <span class="token class-name">ShardMap</span></span> <span class="token punctuation">{</span> ADL <span class="token string">"HAMT/v1"</span> <span class="token punctuation">}</span> <span class="token typedef"><span class="token keyword">type</span> <span class="token class-name">Foobar</span></span> map <span class="token punctuation">{</span>String<span class="token punctuation">:</span>String<span class="token punctuation">}</span> using ShardMap</code></pre> <p>In this example, the declaration <code>using ShardMap</code> says that the <code>Foobar</code> type will be using an ADL, and refers to an <code>advanced</code> clause elsewhere in the schema which must finish defining <code>ShardMap</code>. Then, where the <code>advanced</code> clause states the string <code>"HAMT/v1"</code>, that string is meant to <a href="../naming/">identify the ADL to use</a>. (Note that the schema also still states that it expects that type to be a <a href="/docs/schemas/features/typekinds/#map"><code>map</code> kind</a> -- this is because ADLs "aren't special"; they're just presenting a plain datamodel kind to the schema layer when applied, and the schema layer still needs to turn that into a typekind. Or from another justification: a human reading the schema should still know what typekind to expect here even if they have no idea what the ADL implementation is.)</p> <p>Schema-based signalling is a very useful mechanism because it works recursively!</p> <p>For example, imagine you're specifying a filesystem-like protocol, and you want directories to use an ADL for sharding. You can simply declare that your directory type uses an ADL, say what it is, and say it acts like a map -- done! This will automatically work for all directories, no matter how deeply they may be nested. Declaring this is as simple as:</p> <pre class="language-ipldsch"><code class="language-ipldsch"><span class="token typedef"><span class="token keyword">type</span> <span class="token class-name">Dir</span></span> <span class="token builtin">union</span> <span class="token punctuation">{</span> <span class="token punctuation">|</span> Data <span class="token string">"leaf"</span> <span class="token punctuation">|</span> DirMap <span class="token string">"dir"</span> <span class="token punctuation">}</span> <span class="token typedef"><span class="token keyword">type</span> <span class="token class-name">Data</span></span> Bytes <span class="token typedef"><span class="token keyword">advanced</span> <span class="token class-name">ShardMap</span></span> <span class="token punctuation">{</span> ADL <span class="token string">"HAMT/v1"</span> <span class="token punctuation">}</span> <span class="token typedef"><span class="token keyword">type</span> <span class="token class-name">DirMap</span></span> map <span class="token punctuation">{</span>String<span class="token punctuation">:</span>Dir<span class="token punctuation">}</span> using ShardMap</code></pre> <p>The Schema chapters of the documentation include a whole page on <a href="/docs/schemas/features/indicating-adls/">Indicating ADLs with Schemas</a> which talks more about this.</p> <h3 id="signalling-with-selectors" tabindex="-1"><a class="header-anchor" href="#signalling-with-selectors">Signalling with Selectors</a></h3> <p><a href="/glossary/#selectors">Selectors</a> can contain clauses which indicate that an ADL is to be applied at certain positions during the walk that the Selector is guiding.</p> <p>See the <code>InterpretAs</code> clause in <a href="/specs/selectors/">the Selector spec</a>. It can be placed anywhere within a Selector expression to say "apply an ADL here, before continuing the traversal". The selector expressions which are children of that clause will then be evaluated on the synthesized ADL node.</p> <h3 id="signal-suites" tabindex="-1"><a class="header-anchor" href="#signal-suites">Signal suites</a></h3> <p>Suites which imply Signalling: some programs and protocols will implicitly (or explicitly) have <em>suites</em> of logic which may include ADLs (and maybe other special behaviors that don't fit a clean plugin system) which are signalled by some protocol-specific mechanism.</p> <p>A signal "suite" is differentiated from the other approaches to signalling in that it's been reduced down to <strong>one value</strong> -- or possibly even zero values, and the application itself implies a single fixed suite -- and that choice is considered suffusive in that application or protocol.</p> <p>Signal suites can be implemented in several ways:</p> <ul> <li>Some applications may handle the signal value by using <a href="#code-directly-without-signalling">code directly</a>.</li> <li>Some applications and protocols may treat the signal value as a <strong>shorthand</strong>, and simply hand that off to other standard mechanisms like <a href="#signalling-with-schemas">schemas</a>.</li> </ul> <p>Signal suites are a very common choice, because it's the one with the least cognitive overhead for application developers, and requires the least up-front planning. If one just "starts writing code" and does no special planning, one ends up with an implicit single "suite" for the whole application. If one does think about evolvability, but doesn't want to do anything user-configurable or extensible, then a single "suite" is a very minimal and easy incremental step: it's easy to add a single field to a protocol and declare it's for future-proofing by supporting a signal suite value, and start by hardcoding one value to that, and <em>that works</em>. (It's also neat to observe that one can implement the initial behavior as a "suite" backed by a <a href="#code-directly-without-signalling">code directly</a> system, and then add a future "suite" which just hands off to use of one of the other more standardized and user-configurable signalling mechanisms!)</p> <p>Signal suites aren't very standardized; by nature, they're usually "grown" (and sometimes become well-described only in retrospective). Applications and protocols generally end up with their own specific enum values to name their well-known signal suites, and with their own unique place to convey the suite signal.</p> <p>For an example of signal suites in the wild, consider IPFS. Many of the APIs, both in the CLI and the HTTP API of IPFS, implicitly work on UnixFS. Some of the APIs work on the raw IPLD Data Model, and don't consider UnixFS at all. Generally, in the CLI of IPFS, it's the command name itself that's doing the "signalling" here. In the HTTP API, similarly, a prefix of the URL path (or sometimes even a subdomain) may be doing "signalling" work and causing the UnixFS "suite" to be engaged.</p> <p>While they are easy to do, note that there are several downsides to bespoke signal suites:</p> <ul> <li>First, it doesn't help you tap into other IPLD features. For example, protocols like <a href="/specs/transport/graphsync/">Graphsync</a> can only give you their maximum powers if you can communicate your ADL signalling in a standard way that Graphsync can understand. Bespoke signal suites aren't that.</li> <li>Second, if one is working on a project that wants to build an ecosystem and become user-extensible, bespokeness is not to your advantage. By having a signal suite of your own defining, one inevitably ends up with the need to begin "gatekeeping" the list of signal suites identifiers that are well-known in their system. This just is no fun.</li> </ul> <p>If you're building a protocol that hosts other protocols, or an application that hosts user-defined data, it may be preferable to consider using some other more standardized and user-extensible signalling system, such as <a href="#signalling-with-schemas">signalling with schemas</a>.</p> <h3 id="signalling-in-band" tabindex="-1"><a class="header-anchor" href="#signalling-in-band">Signalling in-band</a></h3> <p>Signalling in-band refers to a broad category of approaches: if the idea is based on some part of the raw data containing a special piece of data that says which ADL to use, we call that "in-band signalling".</p> <p>We tend to recommend against in-band signalling, in broad strokes, because it runs contrary to the idea that ADLs should be like lenses, and that one should be able to use any ADL one wants to process some data, or use more than one, varying the choice by context.</p> <h3 id="combining-signalling-mechanisms" tabindex="-1"><a class="header-anchor" href="#combining-signalling-mechanisms">Combining signalling mechanisms</a></h3> <p>You can write systems and protocols which use more than one signalling mechanism.</p> <p>For example, it's no problem to have an API with parameters (or even defaults) that use some application-specific <a href="#signal-suites">suites</a>, and also offers a different set of parameters that can take a user-supplied <a href="#signalling-with-schemas">schema</a>.</p> <p>It's also no problem to define an API which takes its main signalling input from a <a href="#signalling-with-schemas">schema</a>, but then allows overriding it (or disabling it) in certain positions via more signals in a <a href="#signalling-with-selectors">selector</a>.</p> <p>Check your IPLD library implementations for what they can support.</p> <h3 id="other-declarative-signalling" tabindex="-1"><a class="header-anchor" href="#other-declarative-signalling">Other declarative signalling</a></h3> <p>We've already listed all of the declarative signalling mechanisms that are currently well-known.</p> <p>However, additional systems are still possible -- just waiting for your invention and specification. Some kind of declarative and recursive system that works without Schemas and is also independent of Selectors could be interesting, for example. If you still want to try to specify such a system, draft a proposal!</p> <p>Today, however, it's probably worth trying to use one of the systems that already exists. See if one of our mechanisms detailed above can solve your problems today.</p> <h2 id="signalling-vs-picking-an-algorithm" tabindex="-1"><a class="header-anchor" href="#signalling-vs-picking-an-algorithm">Signalling vs Picking an Algorithm</a></h2> <p>Signalling that an ADL is to be used at all is half the battle. Thereafter, one an IPLD library also has to react to that signal by figuring out what ADL algorithm you wanted; getting some code that does it; and then actually applying.</p> <p>These other steps are covered in the page on <a href="../naming/">Naming ADLs</a>, and <a href="../dynamic-loading/">Dynamic Loading</a>.</p> </div> </main> </body> </html>