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" <[email protected]> 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" <[email protected]> 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.
