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
