Pubsub is different but PEP shares it's subscriptions with roster, so you may look at your roster as on your "Friend list" and build a protocol to share your friend list. What's wrong with it?
On 02/11/2013 11:02 PM, Ashley Ward wrote: > The problem with this list being maintained by the server is that there is > no central point where all of a user's pubsub subscriptions are stored. > The user's server could track all their subscriptions, but this would be > prone to errors and would necessitate their server understanding pubsub to > some extent. Another way could be for individual pubsub services to > provide this information, and to provide some kind of discovery method to > find this out, but you would still have to find out which servers to query > somehow. > > I'm really struggling to think how this could work. > > To do this with roster items would be reasonably trivial as the roster is > only stored on one server, but pubsub is a whole different ball game! :) > > -- > Ash > > On 11/02/2013 13:24, "Sergey Dobrov" <bin...@jrudevels.org> wrote: > >> I am trying to show that this list should be maintained by the server. >> But probably this thing should not rely on PEP at all, it could be done >> as separate "friend sharing" XEP. >> >> The only thing subscription list for a pubsub node can be useful is to >> see which users have subscribed to some topic, but I don't see any >> urgency in this feature, we have many more important problems with >> pubsub now. >> >> On 02/11/2013 08:04 PM, Ashley Ward wrote: >>> Then perhaps we could just go full circle back to where you started and >>> have a simple xep which says something along the lines of >>> >>> - >>> If an entity wishes to make pubsub subscriptions publicly available then >>> the entity MAY publish them to a PEP node with the id >>> 'urn:xmpp:pubsub:subscriptions'. The entity SHOULD ensure that this >>> information is kept up to date. >>> - >>> >>> ^ The point here is that the entity is deliberately publishing and >>> synchronising this information (and can therefore selectively only >>> publish >>> subscriptions which should be public), rather than it just being >>> automatically available. >>> >>> This is pretty much exactly what you originally suggested so I'm sorry >>> for >>> taking you round the houses! :) >>> >>> I was coming from the other angle where the server makes this >>> information >>> available on the entity's behalf (which makes everything far more >>> complicated!). >>> >>> You still have the issue that the client needs to keep the subscriptions >>> node in sync, but I don't think this should form part of the spec - it's >>> up to the specific xmpp client as to how it manages this. >>> >>> :) >>> >>> -- >>> Ash >>> >>> >>> On 11/02/2013 12:41, "Sergey Dobrov" <bin...@jrudevels.org> wrote: >>> >>>> Obviously, the most simple way is to make application specific >>>> extension >>>> and forget about it... Until the moment another client will implement >>>> it's own version of the same protocol (we should agree that the problem >>>> is widespread enough). Then it will become a hell which can be >>>> prevented >>>> earlier than can be achieved this way, I think. >>>> >>>> On 02/11/2013 07:19 PM, Ashley Ward wrote: >>>>> >>>>> >>>>> On 11/02/2013 11:36, "Sergey Dobrov" <bin...@jrudevels.org> wrote: >>>>> >>>>>> This fact will do this protocol even more complicated. >>>>> >>>>> I think this is the exact reason why it should be application >>>>> specific. >>>>> Trying to cover all the bases to make it general purpose would be >>>>> extremely complicated. At the moment your home server doesn't track >>>>> your >>>>> remote subscriptions, and adding this alone would be somewhere between >>>>> difficult and impossible. Add to that the access controls and I think >>>>> it's >>>>> a hugely complex. By making it specific to your application you can at >>>>> least narrow down the functionality to what is required specifically >>>>> for >>>>> movim without having to add the extra complexity to make it more >>>>> generally >>>>> useful. >>>>> >>>>> This is similar to what buddycloud does. It makes a node available on >>>>> your >>>>> home channel server which contains a list of your subscriptions. This >>>>> is >>>>> relatively straightforward though as the buddycloud server implements >>>>> the >>>>> pubsub service directly as an xmpp component, meaning that the same >>>>> code >>>>> which serves the subscriptions node is also the single source of truth >>>>> for >>>>> your subscriptions. >>>>> >>>>> Movim (as far as I understand) is essentially an xmpp client and uses >>>>> existing pubsub services, meaning that the client would have to >>>>> manipulate >>>>> the subscriptions node and ensure that everything remains in sync, >>>>> making >>>>> it more complex. >>>>> >>>>> Sharing roster information (rather than pubsub subscriptions) would at >>>>> least be more manageable than sharing pubsub subscriptions from a >>>>> technical point of view (since your home server actually does know who >>>>> is >>>>> on your roster), but I believe this isn't what you were originally >>>>> asking. >>>>> >>>>> Just my €0.02! >>>>> >>>>> -- >>>>> Ash >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> With best regards, >>>> Sergey Dobrov, >>>> XMPP Developer and JRuDevels.org founder. >>> >>> >>> >> >> >> -- >> With best regards, >> Sergey Dobrov, >> XMPP Developer and JRuDevels.org founder. > > > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
