I have started the changes that were discussed in
https://github.com/xsf/xeps/pull/78
I took the approach of ONLY defining entity versioning in terms of the
roster in the document, and indicating that one should write a new XEP
for other entity versioning "profiles" which would be tracked in a
registry. I plan on writing an EV profile for MUC disco#items (based
on the examples from the previous version of this XEP), and possibly
for service discovery requests.
This update also mentions that clients may request a partial list (or
updates to a partial list) from the server, and that the server may
choose to send down a partial list at any time (eg. it may send down
only a part of the roster that it thinks the client is most likely to
use on first sync, and send down other roster items as they become
necessary or on subsequent syncs at its disgression).
The last part of the puzzle which remains undocumented is an "auto
complete" IQ which allows the client to query for list items that
match a certain simple search criteria. This way even a client with a
partial view of its roster can still show all contacts that match a
given input in, eg. an "auto complete" view or in some other search.
This combination of roster versioning and the ability to do a partial
sync of the roster (or other list) should allow this approach to scale
to even the largest lists. Eg. a group with 10,000 shared users in the
roster may choose to only send down the 500 that it thinks the client
is most likely to contact. As the client works, performs searches,
requests more roster itmes, etc. it could add to that list. In this
way, the user never has to wait for the entire roster to be
downloaded. The roster is simply slowly "discovered" over time.
Feedback on the initial PR, and the ideas for how this will work in
the future (once the "auto complete" IQ is specified) are welcome.
Best,
Sam
