review rating

[robotnic]

I managed it to rate topics. But how to get the rating result?
At client side I'm able to read all replies and calculate the rating.
This is not scale able (think of a topic with 10000 ratings) and I'm wondering if there is a better method to do that.

see https://buddycloud.org

[lloydwatkin]

I agree but this seemed the clearest path when we first added the feature in line with ATOM standards. I'd be happy for you to propose (and then we can look to code up) an alternative :)

[robotnic]

rating vs. text reply

https://xmpp-ftw.jit.su/manual/extensions/buddycloud/#item-replies

Is there a possibility to select between rating comments and text comments? I don't want to show the "rating: 5.0" in the timeline.

rating vs. like

facebook, google, twitter have like, +1, favorite but no rating.
I would prefer to have a +1 functionality instead of a rating by numbers from 1.0 to 5.0.

subitem rating

At the moment it's not possible to reply to a reply message -> It's not possible to rate a reply.

the result

{
   entry:{
     atom:{
....
   }},
   likecount:12
}

or

{
   entry:{
     atom:{
       likecount:12

....
   }}
}

[lloydwatkin]

Previously I've used a rating of 5.0 to represent a '+1' (i.e. binary rating). If we were to implement our own +1/like then we'd need to use a buddycloud namespace within the ATOM document, we'd also probably want to say who liked the post, e.g.

<likes xmlns="http://buddycloud.org/v1#likes">
    <count>12</count>
    <entries>
        <entry>[email protected]</entry>
        <entry>...</entry>
    </entries>
</likes>

[robotnic]

5.0 for+1 is ok for me.

This is not scaleable

<likes xmlns="http://buddycloud.org/v1#likes">
    <count>22888</count>
    <entries>
        <entry>[email protected]</entry>  //number 1
        <entry>...</entry>    //number 2
        ....
        <event>...</entry>   //number 22888
    </entries>
</likes>

To see who liked is already possible incl. rsm.

[imaginator]

Likes can happen when you pull the initial feed at startup or during the client session. I think @lloydwatkin's approach tries to deal with them as a stream of events for connected clients.

[robotnic]

That's all I need:

<likes xmlns="http://buddycloud.org/v1#likes">22888</likes>

And:

socket.send(
    'xmpp.buddycloud.items.replies',
    {
        "node": "/user/[email protected]/posts",
        "id": "1234-5678-9012-3456",
        "type":"comment|rating"    //something like this
    },
    function(error, data, rsm) { console.log(error, data, rsm) }
)

[lloydwatkin]

@robotnic its not quite that simple. Whilst this may be useful for your use case we need to consider the bigger picture too.

Also:

• Do we update the updated date in the database (so liked posts return to the top)
• Do we update the updated date in the ATOM data
• Should we store a date that the user likes the post
• How do we search posts liked by a particular user

[robotnic]

• no
• no
• already stored in reply
• can be added later

[lloydwatkin]

I see what you are saying, add a count to the parent but still post the review item?

[dwd]

I'll get to this in my ridiculously over-enthusiastic database restructuring project. Ratings have been winding me up somewhat since I found the LIKE for finding them.

[lloydwatkin]

@dwd technically we should be using an xpath selector to find then, the like was a quick implementation that hadn't/hasn't yet been fixed.

[dwd]

Or just pull them out into a different column.

[lloydwatkin]

Then buddycloud starts to become ATOM specific rather than general purpose. Meta data could work and use a processor in code to turn that meta into a valid set of elements for the post type

[imaginator]

/user/<jid>/posts is atom formatted, but we also have content type plugins. What about using something like /user/<jid>/post-likes for likes in a new format format?

[dwd]

In all honesty I'd rather remove atom entirely; I'm not convinced it's adding much value at this stage. But that aside, I don't think it's worth adding a new node yet. Adding additional data to the database while keeping the protocol unchanged, though, doesn't force any impacts further up the stack.