Le mardi 9 avril 2013 16:18:24 Sergey Dobrov a écrit : > > see it in examples. So I think: > > * options "publish_model" should be explicit in XEP-0277 > Why?
Because the publish_model must be "subscribers" or "open" to allows commenting, it's useless without it. I guess a mention in 4.2 "Comments node configuration" would be enough > > * this should be clarified in XEP-0060 > What? The publish_model option. So far it's only shown in examples (ex 136, 139, 145, 150, 152 and in §16.4.4 "pubsub#node_config FORM_TYPE"), without any real description exept the labels in §16.4.4. A clean implementation need a real formal desciption of this option in the XEP (even if the example lets guess easily how it works). > > - publishing a link to comments mean we have to request comments for > > each nodes, which can give network/performances overhead. In my opinion, > > a link should be present if comments are allowed, and if there is any > > comment in the node, the parent note metadata should be updated with > > some kinds of "has_comments" option. So if the "has_comments" options is > > True, the client can check the comments nodes, if the "has_comments" is > > False, no need to do a request to the node. > > That behaviour would mean a pubsub extension to links the comments node > > and the parent node. > > I didn't get it. Why do you need "has_comments" if you just see the link > on comments node or don't see? If we don't have this option, we have to subscribe to the comments nodes for each microblog item to know if there are comments or not. In my opinion it should work like this: 1) a client get items of a microblog node 2) on each item, the presence of the <link> tag tell if comments are allowed or not, and where to publish them, as explained in XEP-0277 §3 3) if an other attribute/options/whatever "has_comments" is True, that mean the client can requests comments on the linked comments node. If it's False, no need to ask anything, there are no comments My concern is that if we have something like 100 items in a microblog node, and only 10 of them have comments, we have to do 100 subscriptions to comments node where 90% are useless. With a "has_comments" flag, we only do 10 subscriptions requests. But of course it add some complexity to the pubsub server (not that much, but it has to update the microblog item metadata if comments are posted), so we can let this beside for the moment. > That's interesting but I don't see the reason to do it now, we can't do > even simpler things with pep now. Who will need flexible access models > when we can't do one way subscriptions? I do it because it's an important part in my project, it doesn't break compatibility for clients which don't manage this, and I have a working implementation. Now, making a clean XEP for this can wait a bit, but once we have fixed issues with microbloging/pubsub/pep, I hope to standardize that. > Completely my point of view. How can we fix the issues with PEP? > [SNIP] > Yes, sure, I am continuing to work on it but I am trying to do it most > safely way to be sure it won't be a problem to fix it later with > possible XEP changes. That's why I am trying to implement the very basic > features first, but do it well. But there are things that don't allow me > to do that and I am just a little despair to finish them... Oki, so let's try to fix things. Can you make a summary list of the major blocking issues you have seen ? We can try to fix them together, and ping originals authors of PubSub/PEP/etc. I'm pretty sure I can find other people interested in fixing this as soon as possible (at least one of the main developper of MOVIM). Cheers Goffi On my experimental component, I'm not using PEP because as far as I know it's not possible to have an external PEP componant. But I think an external PubSub componant is important: it's not tied to a server implementation, and we can implement what we need to try the experimental XEPs or other ideas. That's why I have requested an update on RemoteRoster proto XEP.
