Replies to replies
Evan Prodromou
Nathan Rixham
> I'm wondering about encoding conversations with replies to replies. Does
> this look right?
- the { inReplyTo: id } reduces complexity massively.
> {
Evan Prodromou
{
"id": "http://example.com/1",
"author": {
"objectType": "person",
"displayName": "Alice"
},
"objectType": "note",
"content": "Hello, world!",
"replies": {
"items": [
{
"id": "http://example.com/2",
"author": {
"objectType": "person",
"displayName": "Bob"
},
"objectType": "comment",
"content": "Hello, Alice!",
},
{
"id": "http://example.com/3",
"author": {
"objectType": "person",
"displayName": "Alice"
},
"objectType": "comment",
"content": "Thanks, Bob!",
},
{
"id": "http://example.com/4",
"author": {
"objectType": "person",
"displayName": "Charlie"
},
"objectType": "comment",
"content": "That was nice.",
},
{
"id": "http://example.com/5",
"author": {
"objectType": "person",
"displayName": "Denise"
},
"objectType": "comment",
"inReplyTo": "http://example.com/1"
}
]
}
}
My understanding from the "replies" doc was that all the elements in the "replies" list should have an implicit "inReplyTo" to the enclosing object. This encoding breaks that implied relationship.
Typically on processing this kind of data, I'd probably end up building a tree in memory, anyway.
James M Snell
specific needs. Nesting things like in your example is one approach,
but if not managed correctly it can get unwieldy very quickly. Another
approach is to use a flat list that treats replies as activities in
their own right... for instance...
{
"items": [
{
"id": "http://example.org/2",
"actor": {"displayName":"Joe"},
"verb": "post",
"object": [
"objectType": "note",
"content": "this is my reply",
"inReplyTo": [
{"id": "http://example.org/1"}
]
]
},
{
"id": "http://example.org/1",
"actor": {"displayName":"Sally"},
"verb": "post",
"object": [
"objectType": "note",
"content": "this is sally's note"
]
},
}
]
}
This reduces the complexity of the overall structure and allows for a
more efficient streaming model, but puts the burden on the consuming
end to reconstruct the structure of the conversation.
Either approach is valid and has their relative pros and cons. There
are other possible ways of constructing it also.
- James
> --
> You received this message because you are subscribed to the Google Groups
> "Activity Streams" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/activity-streams/-/uThOu3NI0DUJ.
> To post to this group, send email to activity...@googlegroups.com.
> To unsubscribe from this group, send email to
> activity-strea...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/activity-streams?hl=en.
Martin Atkins
implied inReplyTo only applies when there's no explicit inReplyTo, thus
allowing the common case of a flat discussion to be simple while still
allowing a hierarchical discussion.
> Typically on processing this kind of data, I'd probably end up building
> a tree in memory, anyway.
different rendering requirements... not all UIs can accommodate a
threaded discussion, and some impose limits on the level of nesting, so
either:
* Processors that do support threading have to re-constitute the tree
from the inReplyTo relationships, possibly resulting in a tree that has
missing nodes, cycles, or other insanity, or
* Processors that don't support threading have to flatten the tree into
a single list.
It's not clear to me that either one of these is obviously better than
the other, and I believe both serializations are valid per our current
spec...