You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
UIP-0121 proposes %pine: a non-referentially-transparent "request-for-latest" in the namespace. This proposal would allow any piece of data from anywhere within Arvo to be retrievable over the network, as any path can be made referentially-transparent by including the current date.
One problem with this approach is that it places increased, informal responsibility for data availability on the runtime. A datum that is available at time T but not at time T' must then be "fully resolved" at time T. If such a datum is requested over the network via %pine, and it is too large to fit into a single packet (or larger than the conventional batch of packets), the runtime must make special efforts to retrieve and store all the packets of that datum in order to successfully serve the sequence of requests for it.
If %pine is instead restricted to only perform "path canonicalization", the responsibility for data availability stays with Arvo. A non-referentially-transparent "request-for-latest" merely results in the referentially-transparent identifier for the latest version, which can then be resolved normally. In practical terms this reduces the scope of %pine to "frontier discovery" of data explicitly published in the namespace.
The text was updated successfully, but these errors were encountered:
UIP-0121 proposes
%pine
: a non-referentially-transparent "request-for-latest" in the namespace. This proposal would allow any piece of data from anywhere within Arvo to be retrievable over the network, as any path can be made referentially-transparent by including the current date.One problem with this approach is that it places increased, informal responsibility for data availability on the runtime. A datum that is available at time T but not at time T' must then be "fully resolved" at time T. If such a datum is requested over the network via %pine, and it is too large to fit into a single packet (or larger than the conventional batch of packets), the runtime must make special efforts to retrieve and store all the packets of that datum in order to successfully serve the sequence of requests for it.
If %pine is instead restricted to only perform "path canonicalization", the responsibility for data availability stays with Arvo. A non-referentially-transparent "request-for-latest" merely results in the referentially-transparent identifier for the latest version, which can then be resolved normally. In practical terms this reduces the scope of %pine to "frontier discovery" of data explicitly published in the namespace.
The text was updated successfully, but these errors were encountered: