Hello Peter, On Sun, 05 Apr 2009 16:24:33 -0600, Peter Saint-Andre <stpe...@stpeter.im> wrote:
> You are right -- the words "participating full JID" in the first > paragraph of Section 7.2 unnecessarily and incorrectly limit the > matching for collection retrieval. I've fixed that: > > http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0136.xml?%40diffMode=u&%40diffWrap=s&r1=2415&r2=2993&u=3&ignore=&k= ... in fact it seems I've managed to convince several people in the opposite already (including topic-starter) based on current XEP-136 wording ;-) See discussion starting from this comment: https://www.ndl.kiev.ua/content/modarchiveodbc-release#comment-117 Based on the diff I'm not really sure anymore what "retrieve" is supposed to do now: 1) Allowing non-full JID means "retrieve" may match several collections. 2) Phrase "Both attributes MUST be included to uniquely identify a collection" indicates it may not. The following arguments imply that phrase about "unique collection identification" is removed to bring it back to consistent state (and, thus, allow several collections to be matched by "retrieve"). I'm not really sure that allowing to select several collections in "retrieve" is such a good idea for the reasons mentioned in discussion at the link above - to rephrase it shortly here, in my opinion "list" gets the list of all collections matching some criteria, while "retrieve" gets all messages _within specified collection_ matching some criteria. Such change means that "retrieve" starts partially overlap with "list", and this extension is not very natural: 1) "retrieve" still cannot be used to perform the same functionality as "list": it does not support "end" attribute and gives different meaning to "start" attribute thus not allowing queries within given time range, and it already uses RSM to limit messages retrieved, so RSM cannot be used to limit collections matched. 2) How RSM limiting of messages should work across several different collections matched in single "retrieve" command? If it should treat all messages as "linear" list, so that RSM-limited "retrieve" over several different collections is a kind of sliding window, then we're back at our argument about using change notifications in RSM, as then individual collections versioning does not really help us anymore to detect changed collections if change happened between two successive RSM queries. I see two possible solutions: 1) Keep things like they were before, so that "retrieve" may return messages from one collection only. Requires rollback of the last change to XEP and removing "exactmatch" support by "retrieve" from 10.1 and from XML Schema. 2) If support for several collections in "retrieve" is really required, then some work should be done to bring all other dependent things to consistent state: extend "retrieve" to support all the same attributes as "list" does, allow two different RSMs (for collections and messages) in "retrieve", specify the way RSM for messages works when multiple collections are matched, and also I think that adding "changes notifications" to RSM is inevitable then. -- Good luck! Alexander
