Le 11/02/2013 17:02, Ashley Ward a écrit :
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" <[email protected]> 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" <[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.
--
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.
Sorry for this misunderstanding, I will try to explain myself more clearly.
Our goal here is just to allow a jid to share SOME of his subscribed
nodes on this PEP node.
Threw the Movim UI the user will be able to manually add/remove some of
the items of this list to share them with his contacts.
Tim
