Le mardi 29 octobre 2024, 13:57:56 heure normale d’Europe centrale Stephen Paul Weber a écrit : I completely understand your concerns, but I believe it is healthy to refine and improve features based on previous experiences. This is not the first time we have taken such an approach. I have been working with file sharing in Libervia for years and have encountered numerous issues with the current specifications. Moreover, none of the previous extensions (which I reference in the introduction of this proposal) have seen widespread adoption. Therefore, I don't think writing a new XEP based on real-world experience and previous experiments is a big deal. XEP-0135 not only lacks support for notifications but also misses several key pubsub features, such as item retraction, access and publish models, item attachments, full-text search, end-to-end encryption (E2EE), and metadata. Attempting to add these features would essentially involve redesigning pubsub, which could lead to a poorly integrated solution. Here are some use cases for notifications: - New Document Notifications: In a company file-sharing server, you might want to be notified when a document is available to your team. - Update Notifications: If you are working on a document, you need to know when a new version is available. - Inotify Equivalents: Notifications can serve similar purposes to inotify for monitoring file changes. - File Synchronization: Keeping a shared directory up to date with other peers or file hosting services. - Backup: Automatic download of new or updated files for backup purposes. - Community Updates: Notifications for new content, training courses, or other updates on a file-sharing hosting service. - Photo Albums: Notifying users of new albums or photos in a photo album application (e.g., Libervia has this feature). - Local Cache Optimization: Avoiding frequent pulls by receiving notifications for large directories. - Automated Workflows: Triggering actions on new or updated files. The syntax is not entirely new; it is strongly based on XEP-0447, which I believe is well-designed. XEP-0135 uses its own mechanisms, which were designed before Jingle was created. For example, there is no way to integrate XEP-0358 with XEP-0135. We have discussed file-sharing use cases in the xsf@ MUC where waiting for hash calculations to list shared folders is undesirable. XEP-0135 uses a kind of "hack" to enable tree listening (with its tree.xml), while this feature is already available through PubSub and my other proposal (PubSub Extended Discovery). My specification can be used with any generic PubSub service, without requiring a dedicated implementation. So, in addition to adding the subscription/access model part of pubsub to XEP-0135, we would have to change the way file metadata are handled and add item retraction/update functionality. In short, we would have to rewrite the entire XEP to lead to something similar to my proposition, but with a less coherent and potentially broken pubsubish-like addition instead. On the other hand, my proposal strongly relies on existing specifications. On the client side, if you have already implemented PubSub and XEP-0447, you essentially have it. I hope this clarifies the need for this new specification. Best, Goffi