Thanks for taking time to write this - it's very well
thought out. I admit I've had some thoughts along these lines as
well, but in general ended up de-prioritizing them. Let me answer
these by number :
1) Clearing all items is, according to XEP-60
something only a UserRoles.OWNER is capable of doing. We've been
pretty persistent in following the XMPP rules as much as possible,
for reasons that will be clear later =). Likewise, only an OWNER
can delete a node, which clears all items in the node. So for cases
where we've needed to delete all items, we simply delete the node
and re-create it. It meant one less client-to-server RPC to handle,
which in the balance of things is actually a real benefit - we're
pretty stingy about the number of client-server operations we want
to support (while, hopefully, being generous with the number of
features we support).
2) I hear what you're saying here - I think the most
important point being the atomicity of pass/failure of a batch of
events. I don't think I agree with the whole justification you lay
out, however. There would be some bandwidth
savings, but I'm not convinced it's significant; it avoids
repetition of the RPC name ("publish!tem"), the node name,
and the publisherID for each item, but that's essentially it.
More importantly, to your 4*4 grid example, there is actually
guaranteed ordering to messages sent within the same
collectionNode, so they would definitely appear in the order in
which you sent individual items. This wouldn't prevent interleaving
of other publishers' items, which might be a use-case that's
important, but I'd thought about it and couldn't come up with
anything concrete. Any ideas there?
3) More or less the same answer as 2). The biggest case I can
make here is for bandwidth savings, and I think I dispute that it's
"far superior". If I'm missing something here, definitely let me
We do take these sorts of suggestions very seriously - in
fact, it makes me happy to have someone to talk to about
CollectionNode type stuff =). In this case these were all features
we'd considered as part of the design; they got cut as optional,
since they fell more along the lines of "optimizations" rather than
"features" that unlock functionality that couldn't be accomplished
any other way.
Again, thanks for the great suggestions - please keep
digging, and if we're missing anything that wouldn't be possible
with what we have today, we're all ears.
[PS, while trying to submit this post, I was stopped by a
very unhelpful alert message telling me "Censored word(s)
detected". But of course, it didn't tell me which word(s) I needed
to eliminate. So I had to binary search through the post, cutting
out halves, until I discovered the censored word was "publish!tems"
(replace ! with I). This forum software is total bullsh!t.]