1·
1 month agoThat wasn’t in my original doco and I’m not using it currently. I’ll need to see what problem is solved by having Context before I offer an opinion.
I recall @[email protected] took issue with the fact that ‘context’ and ‘target’ are the same object and he felt this was duplicitous. There’s also a bit of an issue that a “partial object” (defined in FEP-400e) isn’t really defined anywhere in the base specs either - and perhaps using Context will help resolve that.
Since it’s a SHOULD, my original implementation is arguably compliant with the FEP without it.
Conversation containers does send a ‘Remove’ if something is removed from a collection. But we typically don’t waste resources on spammers, so we don’t necessarily send a ‘Remove’ if we decided not to add it in the first place (perhaps due to comment controls, permissions, or blocks). You can send these as Remove activities if you want, but please don’t force me to do so.
If you’ve fetched a conversation collection, it would be most common to do so in order to cache the conversation locally. In this case storing under local entities is going to be much more efficient if parents are stored before their children, so the InReplyTo can be pointed to an existing stored entity. If you do it backward, it’s kind of awkward.
That said, our implementation of Collection objects has a flag to reverse the returned item order. So as long as the order is defined and isn’t going to change, I don’t actually care what it is; beyond the storage efficiency mentioned above. We need to sort it how we want after fetch anyway, because that’s just basic input sanitisation.
It would seem most natural to me to send the collection in “thread” order - start from the root and recursively traverse every branch/leaf encountered. I’ll mention this for consideration – but again I really don’t care.