A couple of thoughts: * Please don't use PEP for this. To support other servers you will end up rewriting your code. * Please don't use PEP for this. To update code you have to wait for the XMPP server team to put out a new release * Please don't use PEP for this. If I read this thread correctly, you are are doing crazy things to work around PEP following restrictions and and to enable commenting.
Seriously - if you want this to fly, you don't want your code changes to be bound into the XMPP server core. (as an analogy, imagine if your JAVA application server had to be build into the core of Apache - shudder). You end up with a big pile of unmaintainable gunk and lots of finger pointing. Think of XMPP as your dumb message router and build any intelligence into a component roughly based on pub-sub. Now you can extend your application quickly, put out new releases without needing to wait a year between new versions of $XMPP-SERVER and your code will work against any XMPP server. S. On 10 April 2013 07:52, Sergey Dobrov <bin...@jrudevels.org> wrote: > On 04/09/2013 07:25 PM, Goffi wrote: > > 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 > > I don't agree here. Any publish model can be useful in some cases here. > I don't see the reason to make such artificial restriction. > > > > >>> * 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). > > Ah, Yes, this needs to be clarified. This is not the only problem in the > XEP-60. > > > > >>> - 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: > > Sure you need to subscribe to each comments node if you want to track > the comments there. How do you want to see if someone suddenly commented > the thread? > > > > > 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. > > I don't understand why do you think that the one more subscription to > the node is something bad. Your solution doesn't make things simpler but > do them unobvious. > > I know ejabberd had (have?) big problems with such scenario but the > problem in the particular server should not affect the protocol. I don't > see other reasons to make things more complex here. > > At the other hand, it's a problem to list all subscriptions and, for > example, unsubscribe from all threads because nodes can be served on > different servers. I think we can invent the new XEP here which will > allow server to track user's pubsub subscriptions on all servers just > for informational goals. > > > > > > >> 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. > > > > It's ok, but I want to warn you that the compatibility may be broken at > the moment such feature will be standardized. > > > > >> 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). > > I have posted such list several times at this list and one time emailed > to Peter. I don't want to find all the pieces of information now, so > I'll just copy the incomplete list I have sent to Peter: > > > 1. PEP doesn't work with to and from subscriptions. This is the biggest > problem of PEP at the moment. I think so because without support of > non-both subscription it's hard to build complex protocols based on PEP: > such protocols often need a big amount of subscribers and this way > publisher will be abused with a lot of undesirable information and > benefits of caps will be missed. Also, this thing is a base for social > interaction so we can't lose that. There are several ways to solve that, > some of them can be backward compatible, some of them were discussed in > the mail list. > 2. Metadata. We are solving the problem now but there are few questions > I asked in the list still unsolved. > 3. Blogs or microblogs? I already mentioned that I think that the > difference between blogs and microblogs is too artificial. We already > have some features in XEP-277 which are traditionallyб═ not concern to > microblogs. But I really consider that there is no reason to divide > these things into a different specs. Maybe it will be useful to divide > more general XEP and then define two different namespaces (i.e. node > names in terms of PEP) for blogs and microblogs with some > recommendations (i.e. best practices) for both. > 4. Quality of current pubsub implementations is poor. I think that the > reason of it is that current application level protocols that based on > pubsub are too simple and doesn't consume all the power of pubsub. So, > this fact in additional to defects in specs leads to less interest to > the technology. I think that blogging technology can be a leader of > pubsub progress because of wide usage. Also, maybe that it is time to > invent new XEP to allow to implement such protocols as PEP or "Private > XML storage" as separate components. It will facilitate migration from > server to server and will increase speed of implementing new technologies. > 5. Items filters. The another thing I already mentioned in our > discussions a little. We need some mechanism to check published items > and possibly modify them. It would be better that filters can be > processed in a chain. This could be useful for spam filtering which is a > big big problem in distributed networks I think, and another thing is to > modify content by aggregators (like addition of some metainformation > like an HTTP URL). > > For the second item I have prepared the XEP-0315. It's experimental and > I don't know if it's possible to link XEP-0060 to an experimental XEP > but the problem is that this XEP is not useful anywhere else, so it > won't quit the experimental status otherwise. I have sent to Peter my > edits to XEP-0060 that uses XEP-0315 to serve node metadata but did not > receive any answer. Don't sure if Peter has received it at all. > > Also, a long time ago I have sent a letter to this list where specified > that 7.1.2.3 "Item Publisher" section is unclear in XEP-0060 and it's > impossible to know if the pubsub service will send stanzas with > publisher attribute. There is no any suitable solution yet. > > I have more, but should I post them here? :) I did it many times... > > > > > 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. > > > > > Yes, I agree here, and the forth item was a subject to discuss here a > long time ago too. > > > -- > With best regards, > Sergey Dobrov, > XMPP Developer and JRuDevels.org founder. > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
