Hi Goffi, On Sunday, March 10, 2013 06:36:43 PM Goffi wrote: > I'm implementing comments in my client (http://sat.goffi.org), so I > bring up this long and interesting conversation because I think there > are some points which still need some discussion: > > - I think that comments must not be in XEP-0277 but in a separate one: > comments are not only useful for microblogging. There are good points in > XEP-0303, but I don't like the activity stream idea, and I more think > like Sergey that the same goal can be achieved with a more generic > pubsub journal XEP. The issue with the 303 is that the pubsub service > should have a different behaviour to compile the activity stream to the > /comments node, that mean a service dedicated to comments and a > management depending on node name, which is not really KISS.
It's true, XEP-303 requires "code-on-a-node". The challenge with comments is easily enabling applications to render an initial display. If you want to be able to display the first "page" of comments with nested replies, you need a query that involves some complex filtering. Out of the box, the XEP suggests being able to query for items by a list of parent ids. This means that a client will have to do an iq request for each depth of the render desired (e.g. showing 4 levels of nesting would require 4 queries). Long term, I think it would be useful to define an extension for getting an entire page of nested comments in a single request, but this gets gnarly on the server and at first I didn't want the XEP to be hard to implement. The reason for having two nodes is because I see a major distinction between raw activity and the compiled form. If you submit a comment, delete it, submit another, and delete that one too, then raw activity will have 4 items but compiled will have 0. FWIW, at Livefyre, comments were/are stored in a compiled state for populating the initial view and paging back in single requests. I think the only way to avoid code-on-a-node is to define more advanced pubsub mechanisms. For example, maybe there could be some "pubsub item compilation", "pubsub identity stamping", "pubsub publisher validation", etc specs. Also maybe some existing specs could have use, like pubsub collections for nesting. > - ordering/filtering is actually needed, as suggested by Justin. Maybe > not url encoded but more with some kind of option in the stanza I have no objection to this. Maybe we could reuse the subscription options format and allow it to be used with items requests. > - what about anonymous comments ? XEP-303 doesn't touch on anonymous comments, but the way I'd implement it is: services should have a policy for whether to accept anonymous comments or not, and if not then the server would need to disco a submitter before accepting the comment. There is already suggestion in the XEP that the service should fetch the submitter's vcard, so the service ought to be prepared to do these kinds of reverse requests. If accepted, the item would be stamped with the anonymous JID as identity. Justin
