review rating #312

Activity

1. lloydwatkin commented on Aug 16, 2015

   

   lloydwatkin

   on Aug 16, 2015

   Member

   More actions

   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 :)
2. robotnic commented on Aug 17, 2015

   

   robotnic

   on Aug 17, 2015

   Author

   More actions

   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
   
   ....
      }}
   }
   
3. lloydwatkin commented on Aug 17, 2015

   

   lloydwatkin

   on Aug 17, 2015

   Member

   More actions

   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>lloyd@buddycloud.org</entry>
           <entry>...</entry>
       </entries>
   </likes>
4. robotnic commented on Aug 17, 2015

   

   robotnic

   on Aug 17, 2015

   Author

   More actions

   5.0 for+1 is ok for me.

   This is not scaleable

   <likes xmlns="http://buddycloud.org/v1#likes">
       <count>22888</count>
       <entries>
           <entry>lloyd@buddycloud.org</entry>  //number 1
           <entry>...</entry>    //number 2
           ....
           <event>...</entry>   //number 22888
       </entries>
   </likes>

   To see who liked is already possible incl. rsm.
5. imaginator commented on Aug 17, 2015

   

   imaginator

   on Aug 17, 2015

   Member

   More actions

   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.
6. robotnic commented on Aug 17, 2015

   

   robotnic

   on Aug 17, 2015

   Author

   More actions

   That's all I need:

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

   And:

   socket.send(
       'xmpp.buddycloud.items.replies',
       {
           "node": "/user/lloyd@evilprofessor.co.uk/posts",
           "id": "1234-5678-9012-3456",
           "type":"comment|rating"    //something like this
       },
       function(error, data, rsm) { console.log(error, data, rsm) }
   )
7. lloydwatkin commented on Aug 17, 2015

   

   lloydwatkin

   on Aug 17, 2015

   Member

   More actions

   @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
8. robotnic commented on Aug 17, 2015

   

   robotnic

   on Aug 17, 2015

   Author

   More actions

   • no
   • no
   • already stored in reply
   • can be added later
9. lloydwatkin commented on Aug 17, 2015

   

   lloydwatkin

   on Aug 17, 2015

   Member

   More actions

   I see what you are saying, add a count to the parent but still post the review item?
10. dwd commented on Aug 17, 2015

    

    dwd

    on Aug 17, 2015

    More actions

    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.
11. lloydwatkin commented on Aug 17, 2015

    

    lloydwatkin

    on Aug 17, 2015

    Member

    More actions

    @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.
12. dwd commented on Aug 17, 2015

    

    dwd

    on Aug 17, 2015

    More actions

    Or just pull them out into a different column.
13. lloydwatkin commented on Aug 17, 2015

    

    lloydwatkin

    on Aug 17, 2015

    Member

    More actions

    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
14. imaginator commented on Aug 17, 2015

    

    imaginator

    on Aug 17, 2015

    Member

    More actions

    /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?
15. dwd commented on Aug 17, 2015

    

    dwd

    on Aug 17, 2015

    More actions

    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.