#12 Replies: Serve as a flat list or a hierarchical one?

Open
opened 2 years ago by fr33domlover · 3 comments

In AS2 there's a "replies" property, which maps to the collection of objects considered to be responses to the object being defined. Does this imply these should be only direct replies (i.e. replies is the inverse of inReplyTo), or can it list replies-to-replies too?

Assuming the latter option, we have a choice. Should replies be served as:

  • A hierarchical tree?
  • A flat list of all the tree items?
  • Allow both, using some query parameter in the URI? If yes, which representation is the default?

And if we choose the flat list approach, should the replies have their own replies fields, listing e.g. the direct replies to that comment?

Some thoughts to consider:

  • If a client wants to display the comments as a flat list (like most forges do), and it receives them as a tree, it could first flatten the list using simple list traversal, and operate on that list. And if the client wants to display comments in chronological order, which IIRC is what forges usually do, the client will also sort the flattened list by comment publishing time. I imagine there may be some possibility to traverse and sort in 1 operation, using BFS.
  • If a client wants to display the comments as a tree (like it is often in email / mailing lists), and it receives them in a flat list, it will probably do something like produce a graph (using inReplyTo to create edges) and do graph traversal with edge visit order determined by publishing time, producing the desired tree.
In AS2 there's a ["replies"](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-replies) property, which maps to the collection of objects considered to be responses to the object being defined. Does this imply these should be *only* direct replies (i.e. `replies` is the inverse of `inReplyTo`), or can it list replies-to-replies too? Assuming the latter option, we have a choice. Should replies be served as: - A hierarchical tree? - A flat list of all the tree items? - Allow both, using some query parameter in the URI? If yes, which representation is the default? And if we choose the flat list approach, should the replies have their own `replies` fields, listing e.g. the direct replies to that comment? Some thoughts to consider: - If a client wants to display the comments as a flat list (like most forges do), and it receives them as a tree, it could first flatten the list using simple list traversal, and operate on that list. And if the client wants to display comments in chronological order, which IIRC is what forges usually do, the client will also sort the flattened list by comment publishing time. I imagine there may be some possibility to traverse and sort in 1 operation, using BFS. - If a client wants to display the comments as a tree (like it is often in email / mailing lists), and it receives them in a flat list, it will probably do something like produce a graph (using `inReplyTo` to create edges) and do graph traversal with edge visit order determined by publishing time, producing the desired tree.
fr33domlover commented 2 years ago
Collaborator

(A similar question applies to things like ticket dependencies! Do we list all the ancestors/descendants of a ticket, or just the direct ones? And if the former, do we list them as a tree or as a flat list?)

(A similar question applies to things like ticket dependencies! Do we list *all* the ancestors/descendants of a ticket, or just the direct ones? And if the former, do we list them as a tree or as a flat list?)

Isn't this more of an implementation concern of a server implementing AP, not something that should be locked down in the specification of ForgeFed? Simply because it's also not enforced by Activitypub itself it seems weird if Forgefed did.

Isn't this more of an implementation concern of a server implementing AP, not something that should be locked down in the specification of ForgeFed? Simply because it's also not enforced by Activitypub itself it seems weird if Forgefed did.
fr33domlover commented 2 years ago
Collaborator

@jaywink, I suppose that even if we indeed get free choice on this decision, it would be nice to recommend an option. Also, when a server produces a JSON object, it has to choose how to list the replies/dependencies/whatever. Even if servers can choose freely, it's nice to have a convention/recommendation.

Btw after discussion on IRC, the "list direct replies, not a flattened list of the whole thread" option is probably better and safer and is probably what's expected. The spec just doesn't say it clearly enough to make me feel sure about it, but it's clear enough to make it confusing if things are done in other ways.

I just want that insight to be clearly documented, because it wasn't obvious to me, even if it was to other people.

@jaywink, I suppose that even if we indeed get free choice on this decision, it would be nice to *recommend* an option. Also, when a server produces a JSON object, it has to choose how to list the replies/dependencies/whatever. Even if servers can choose freely, it's nice to have a convention/recommendation. Btw after discussion on IRC, the "list direct replies, not a flattened list of the whole thread" option is probably better and safer and is probably what's expected. The spec just doesn't say it clearly enough to make me feel sure about it, but it's clear enough to make it confusing if things are done in other ways. I just want that insight to be clearly documented, because it wasn't obvious to me, even if it was to other people.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.