Re: [Standards] Microblogging: XEP-0277 and beyond
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? 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. 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. About post deletion, why to have this notification? Is it not enough to receive a regular retract event? I don't want servers to have to maintain an activity log to be compliant though, which is why item persistence on the activity node is optional. A simple server can receive a published activity item, relay it to subscribers, apply it to the comments node state, and then throw it away. 2) Why to use Activity Streams here? I totally misunderstanding why to have such complication since commenting behavior totally get into simple Atom format. AS make the most sense for the activity node. It makes less sense for the comments node though. Perhaps the comments node could be an Atom-only representation. 3) You have filter parameter by parent id but have no any mechanism to represent such relations. But this mechanism is already defined in XEP-277. Hmm, yes. Agree it should be thr:in-reply-to. 4) atom:id MUST be an URI. Oops, you're right. 5) Again, why to url encode a node name? (comments?order=-createdparent_ids=1%2C5a%2Co19g%2C) It was just an easy approach that would work with existing pubsub client libraries. Perhaps a better idea would be to allow options in pubsub iq requests, then we can have an x:data form for the extra parameters. It seems so. Justin -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Microblogging: XEP-0277 and beyond
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. Justin
Re: [Standards] data forms and x- parameters
On 31 August 2011 12:19, Peter Saint-Andre stpe...@stpeter.im wrote: Given https://datatracker.ietf.org/doc/draft-saintandre-xdash/ it seems appropriate for me to lobby for changing the text in XEP-0068. :) Does anyone have concerns about modifying the recommendations in XEP-0068 to align with draft-saintandre-xdash? No concerns about this. I'm a bit concerned after reading the I-D though that we'll start seeing a lot of people using the attribute foobarbazqux :) OT for this list I know, but perhaps it should suggest prefixing with organization name or something if the intention is to keep it human-readable? Regards, Matthew
