[Standards] Microblogging: XEP-0277 and beyond
justin-keyword-jabber.093179 at affinix.com
Fri Sep 2 17:41:58 UTC 2011
On Friday, September 02, 2011 04:29:25 AM Sergey Dobrov wrote:
> On 09/02/2011 03:32 AM, Justin Karneges wrote:
> > On Thursday, September 01, 2011 11:22:30 AM Sergey Dobrov wrote:
> >> Then, my questions about XEP-303:
> >> 1) Why to use three nodes? Info node can be replaced by some item with
> >> some constant id. about necessity of activity node I don't understood at
> >> all, why to have it?
> > I didn't want to put the info item in with the comments since they are
> > not really part of the same collection of data. The gain with a
> > separate node is that you could subscribe to just the 'info', and not
> > the comments, if for some reason you wanted to do that. Maybe that
> > isn't very useful.
> Exactly, maybe we should extend node metadata instead of that?
The drawback to node metadata is it does not support update notifications. I
have the need to track this data, particularly the conversation title.
So I think the data belongs in a node. Or, we could consider adding
notification support for node metadata.
> > I do believe there is a need to have separate comments and activity nodes
> > though, and possibly even more in the future (I want to have an
> > "occupants" node containing a userlist of people with temporary
> > subscriptions -- think MUC over pubsub). So, I have already resigned to
> > needing multiple nodes, and when it came time to need 'info', I decided
> > a singleton made logical sense.
> > The activity node is actually the core node of the system. Flowing
> > through it would be the stream of activity occuring in the conversation.
> > If you want to post a comment, like a comment, delete a comment, etc,
> > it makes sense to publish them as "activity". If you want to receive
> > events for these kinds of activities (e.g. to track the conversation
> > while you are away, and power something like Facebook Notifications),
> > then again you want to be subscribed to items of "activity". This is
> > distinct from the comments node, which only holds the comments in their
> > current state. For example, if a comment is posted and edited three
> > times after that, this would be represented as four items in the
> > activity node but still only one item (updated three times) in the
> > comments node. The comments node is needed to drive application
> > displays. So this is why I believe both nodes are needed.
> I still don't understand. You trying to solve problems with extra
> entities when it should (in my opinion, of course) be solved by some
> generic pubsub extensions, for example, it could be really usable to
> store each item version, so you will be able to retrieve any edits of
> the comment too. But I still consider that activity node is unnecessary
> and comments node should be in a simple atom format.
Activity makes it much easier to determine what has happened to an item. For
example, if a moderator edits a comment, this is easily described in activity
terms. Simply doing complete replacement of comment items is not terrible but
it makes it harder for listeners to figure out what is going on.
The main point is the activity node is an append-only changelog, and the
comments node is an up-to-date compilation of that log.
> Then, I don't understand how "likes" can work in such model, who will
> count likes? I think that this feature should be implemented in
> aggregators, some services which aggregates messages from one or more
> servers and give services of statistics, search or something else.
The plan for likes is you'd publish to the activity node ("Justin likes
comment X"), but on the comment node this would be reflected as a property of
an existing comment rather than a new item. Comment items could have "like"
data stored within them, such as a count and maybe a list of the last five
people to like the comment.
I want to point out again how the activity node makes it far easier to figure
out what has actually happened. If you have a notification app that is
tracking your comments, subscribing to the activity node and listening for
"Justin likes comment X" is much more straightforward than subscribing to the
comments node and making inferences.
> About post deletion, why to have this notification? Is it not enough to
> receive a regular retract event?
Comments node could send a retract event. But activity node is always
appending, and would send some notification such as "User N deleted comment X".
More information about the Standards