Hi Dave, Thank you for your feedback.
> Is XEP-0248 really that poorly implemented in PubSub services? As I recall, > it wasn't that hard to do. 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. > Also, while on the subject of this proposal's critique of its competitor (I > do dislike these marketing screeds in XEPs), the matter of deletion and > security model seems to suggest a misunderstanding of what Collections is > and does. 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. > The deletion is because, amongst other things, a leaf node can belong to > multiple collections, and so deleting a collection certainly should not > delete its leaf nodes - sometimes. 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). > The security model is because notifications "bubble up", and was a > simplification. To do otherwise would mean that the bubble-up needs to > carry the originating node, and ultimately, if you have collections of > collections, a list of nodes to check the access against. I think that's > probably better, but it is more complex to develop and test. But it only > affects the notifications and not more broad access. 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.). > This specification, though, has some interesting limitations - a node can > only be linked to one other, and that node in turn shows no indication of > being a "linked node" - the implementation would have to track this though. 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. > I kind of hate to say it, but it you're going this route, I'd rather see a > more generalized concept of "linking" using the RDF kind of approach, and > a secondary concept of "subordination" to control deletion requirements. 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. > If you approach the problem in this way, then it starts to look like a > complementary system to XEP-0248 that mostly addresses your concerns with > it, rather than a replacement that's broken in its own way. 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). > Does that make sense? I hope that I've made things clearer now; let me know if you have any other comments. Thanks Best, Goffi
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
