15 Oct
2024
15 Oct
'24
10:23 a.m.
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