Hello, I understood nothing. Could you tell us what do you fear about more clearly?
On 04/10/2013 07:50 PM, Simon Tennant wrote: > 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 <[email protected] > <mailto:[email protected]>> 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 <http://buddycloud.com> | +49 17 8545 > 0880 | office hours: goo.gl/tQgxP <http://goo.gl/tQgxP> -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
