From c7a563bd15df92f7aee64d503e40c9208b183381 Mon Sep 17 00:00:00 2001 From: fr33domlover Date: Sun, 2 Jun 2019 09:57:07 +0000 Subject: [PATCH] FEDERATION.md: Write list-direct-replies proposal --- FEDERATION.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/FEDERATION.md b/FEDERATION.md index 675c9a4..e5e72bf 100644 --- a/FEDERATION.md +++ b/FEDERATION.md @@ -582,6 +582,34 @@ This proposal suggests a property named `events`, which maps to an objects that aren't stand-alone and aren't actors can provide a stream of updates. +#### (8) List only direct related objects, not a flattened tree + +There are various properties that typically form a tree or graph structure when +recursively traversed. And often a client may wish to fetch the entire +hierarchy. For example, there's the AS2 `replies` property. The AS2 spec says +it should list objects that are responses. But should/can that include indirect +replies, i.e. objects that are replies to replies, or should only direct +replies be listed, i.e. `replies` is the inverse property of `inReplyTo`? + +In ForgeFed there's similarly a `dependsOn` property for listing a ticket's +dependent tickets, and the question arises there too: Provide a flat list +containing the whole transitive closure of dependent tickets, i.e. dependencies +of dependencies etc., or list the direct dependencies? + +I suppose to some people the answer to this question is obvious, but to me it +wasn't, so I'd like to explicitly propose an answer and follow it. + +`replies`, and `dependsOn`, and similar properties, map to a collection whose +items are the *direct related objects*, not indirect transitively-related +ancestors of descendants. So, `replies` is the inverse property of `inReplyTo`, +and if object A lists object B under `replies`, then the `inReplyTo` field of +object `B` should be pointing back to `A`. + +It's still possible for object `B` to have its own `replies`, of course, +forming a tree/graph of discussion (and `dependsOn` forming a graph of ticket +dependencies). Whether or not those nested objects forming a tree/graph are +provided, is a separate question. See proposal B.4. + ### (C) ForgeFed #### (1) Actors