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.
