Hi Singpolyma, Le lundi 14 octobre 2024, 18:40:01 UTC+2 Stephen Paul Weber a écrit : Not yet, but it's planned. The disco#item will be used; I'm working on two other specifications: one for subscriptions and one for Disco that will add a flag to include children. It’s not set in this proposal for backward compatibility: current clients don’t expect to receive nodes in addition to items when performing a disco#items request on a node (besides XEP-0248 collections, and I’m not aware of any currently maintained client implementing them). With an explicit flag, we don't have any problem. Regards, Goffi

Hi Dave, Thank you for your feedback. As far as I know, it is not available in at least two major server implementations: Prosody and Ejabberd, and I am not aware of any client that has implemented it. Actually, the pubsub service that I maintain, Libervia PubSub (based on Ralph’s Idavoll), does have an implementation, but each time I've wanted to use it, I've been blocked by the limitations mentioned in the protoXEP. Far from my intention is any critique or "marketing" talk. Quite the contrary, I genuinely appreciate the efforts made. However, I also acknowledge the limitations because I've tried to use these implementations for many years and have discussed this at several XMPP summits. In fact, at the last summit, I recall Ralph mentioning that Pubsub collections should not be used. It has nothing to do with "marketing" (which would make little sense for such a niche specification). It's simply a common practice to explain why existing efforts are not suitable and why we're working on a new solution. Frankly, I find this insinuation unwarranted and inappropriate. I understand that this is even mentioned in the section I quoted in my proposal. However, as a result, the state becomes indeterminate: when a client deletes a collection node, we are unsure whether the child nodes have been deleted or if they have been reassigned to another node or the root node, or some other outcome. This is, in my humble opinion, undesirable, and an explicit outcome should be specified (e.g., reassignment if there are still parents, deletion otherwise). Again, it's not a misunderstanding on my part. I got the simplification, but this makes the thing unusable for all the use cases I've wanted to implement (file sharing, "space" like feature with admin child nodes and public ones, use in the context of blogging with comment nodes, etc.). The single parent is by design (but a node can have several linked nodes or child nodes). The node does show the indication in its configuration, and I'm working on two separate specifications to list them easily (I wanted to publish them at the same time, but I've been caught up by other things). There is no need to track them. You are confusing the two states mentioned in this protoXEP: "linking" is a simple relationship (not covered at all by XEP-0248), and "parent" is the subordination one. And I want to keep it simple for easy client implementation with only a simple field to set in configuration. I fail to see what RDF would bring in this context, but I see how it would add unwanted complexity. XEP-0248 doesn't address my concerns. The "linking" case is not handled at all, and the "collections"/"leaf" distinction makes it hard to use as an afterthought for things like XEP-0277 blogs/comments (how would you apply XEP-0248 here in a simple way and without breaking backward compatibility? With my proposal, it's just a single configuration field to set on the comments nodes). I hope that I've made things clearer now; let me know if you have any other comments. Thanks Best, Goffi