[Standards] Microblogging: XEP-0277 and beyond

Sergey Dobrov binary at jrudevels.org
Wed Sep 7 13:39:22 UTC 2011


On 09/07/2011 07:40 AM, Justin Karneges wrote:
> On Sunday, September 04, 2011 11:47:55 PM Sergey Dobrov wrote:
>> On 09/05/2011 12:17 PM, Justin Karneges wrote:
>>> On Saturday, September 03, 2011 03:07:45 AM Sergey Dobrov wrote:
>>>> On 09/03/2011 12:41 AM, Justin Karneges wrote:
>>>>> 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.
>>>
>>> Don't understand why the title of a conversation might change?
>>
>> Yup.
> 
> In my experience a title change for a commenting area is usually only done to 
> correct a typo.  Still, applications that cache titles (think long running 
> apps like web sites) should have a way to keep them up to date.
ok, maybe it can be useful but not a first-time needed feature. anyway,
from my point of view it will be more useful to invent more flexible
metadata protocol for nodes. (i mean, if node configuration changes may
be delivered immediately as event, why metadata can't? but I really hate
producing entities in a kind of nodes)

> 
>>>>> 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?
>>>
>>> It's simple: the activity node has optional persistence, hence the
>>> journal is optional.
>>
>> Journal is optional feature anyway. So it's more usable to make it
>> universal and not force it to depend on an applied protocol, isn't it?
> 
> The activity node is actually the most normal.  It doesn't even define any 
> parameters.  It's the raw stream of what's happening.
It is. But it's not flexible (for other protocols than XEP-303). Again,
I think that it's completely unnecessary complication for servers (since
server should support consistency of that nodes). Pubsub services are
not too ideal without that complications. If we will produce more and
more entities that can not be reused we will have the sad end. So I
think that it will be better to invent FLEXIBLE journal than reinvent it
in each applied protocol.

> 
> The comments node is the weird one.  It's a view/compilation of the activity.
> 
>>>>> 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.
>>>
>>> What do you mean by centralized?  That the conversation is the authority
>>> on all of its replies and likes?
>>
>> Yes, I don't understand what is the reason to have likes in such system
>> if we can't count them globally and give stats.
> 
> The problem with distributing a single conversation across servers is then you 
> need a way of aggregating even in the common case.  Simply viewing the 
> conversation properly with nested threads and like points requires an 
> aggregator.  

>This is what Salmon is for in the HTTP world: telling upstream 
> you've made a reply/like/etc.
But it's already solved in the pubsub world: we have event delivering
system.

>  My humble opinion is that this approach does 
> have some cool-factor but it is also a giant pain in the ass in terms of 
> practicality.
> 
> I think that if we ever did support distributed conversations then you'd still 
> want the main conversation node (root node) to be able to hold copies of all 
> the content (e.g. use a salmon-like process so that the root node remains in-
> the-know and is able to serve the full dataset to clients).  Assuming this is 
> acceptable, then we can always add distribution in the future.
Sure, the particular conversation will be kept in an one node and you
will be able to see what is a count of likes for that node but:

1) a count of likes can be forged very simple
2) why likes is needed if we can't see the world's most liked records,
for example?

> 
> Justin
> 


-- 
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.




More information about the Standards mailing list