[Standards] Microblogging: XEP-0277 and beyond
justin-keyword-jabber.093179 at affinix.com
Thu Sep 1 20:32:40 UTC 2011
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.
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 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
> 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?
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.
More information about the Standards