[Standards] Microblogging: XEP-0277 and beyond
binary at jrudevels.org
Fri Sep 2 11:29:25 UTC 2011
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
>> 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.
It seems so.
With best regards,
XMPP Developer and JRuDevels.org founder.
More information about the Standards