On 09/03/2011 12:41 AM, Justin Karneges wrote:
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.
Don't understand why to change that.
So I think the data belongs in a node. Or, we could consider adding
notification support for node metadata.
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.
That's funny: some earlier you said: "My stance is there is nothing
wrong with using a journal to implement pubsub, but ideally pubsub-using
protocols should not be so complex that they require a journal-based
implementation to participate." And now you talking about inventing the
same journal but in specific (non-universal) way and in much more
complex manner. Why?
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 think that all these actions should not be copied from centralized
services since that services have more possibilities to control them. I
mean, it will be very hard to check if likes are winded by some bad
mans. Also it will be hard to represent some statistics of most liked
items. So I think that these things should be solved in that manner how
google ranking web pages: aggregators will rank items by repost counts
or something. And, yes, for user like button should be replaced by
"repost" or "repost with comment", I have such functionality in my
microblogging service and I want to add it into the XEP-277.
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".
Justin
