I agree with most of your observations, saving all the elements in a single item can create lot of issues if you use multiple clients with the same account. <div><br></div><div>I also see that the Bookmarks implementation is really messy in some clients (I've never successfully synchronize my bookmarks between Pidgin, Gajim and Xabber for example).</div><div><br></div><div>So separate each element in a specific item can be a sollution, I know that the HipChat client works like this. Furthermore you don't have to reparse the all list client side to update or get a specific element of the list.</div><div><br></div><div>So maybe we can define a general algorythm to calculate the hash of the item ID. The old clients will still use the 'current' ID. That way we will be sure that we will not have any issues with items crushed by a messy implementation.</div><div><br></div><div>Tim <br><br>On mer., avril 30, 2014 at 5:43 , Lance Stout <lancestout@gmail.com> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"><blockquote><blockquote> My proposal is quite simple. Take the "subscription" tag used in the XEP-0330 (
 <a href="http://xmpp.org/extensions/xep-0330.html">http://xmpp.org/extensions/xep-0330.html</a>
 ) to store the informations of the subscribed node and put them in Bookmark items.
</blockquote></blockquote>
The only hesitation that I have here is that this is going to create some nasty surprises due to how
bookmarks work with private XML storage. Ie, you have to fetch, edit, and save the entire XML blob
any time you want to make a change. Which is generally fine, but bookmarks are old and there is a lot
of existing code that assumes you are only storing MUC bookmarks (since no one ever actually used the
URL bookmark feature). So if you happen to use the wrong client somewhere, all of your subscription
bookmarks could disappear because they didn't know about subscriptions.


That's certainly wrong behaviour for clients, but such behaviour does exist in the wild.


The safest route is to use what you already have defined in XEP-0330. However, I'll note that PEP services
have not done well in allowing multiple items to be published to a single node like this requires.

XEP-0330 could be changed to save the full set of subscriptions in a single item to work around that, though
I'd really prefer the multi-item PEP nodes.


As a last resort, saving the full set in a new private XML storage element would work.


<blockquote><blockquote> Furthermore it would be great to add some tags on the Bookmark items to organize and filter them.
</blockquote></blockquote>
+1 for this idea. However, it does carry the same consideration as above that older clients could cause you to lose this information.




—Lance
</div></blockquote></div>