Hi edhelas, thank you I understand your intentions better, and the title you chose makes more sense now (I didn't really see the point of XEP at first, now I get it).
Let's see where it goes. Le mercredi 2 novembre 2022, 20:37:01 CET Timothée Jaussoin a écrit : > Atom fits perfectly and is super easy to handle when you want to inject > external feeds or transform a Pubsub node into a simple HTTP Atom 1.0 > url. In any case, even if the item contains XEP-0447 elements I'll still > declare those pictures as attachment to ensure proper Atom compatibility. That's the point, you need a http URL then. How would you do with files that need to be retrieved with jingle FT or other XMPP specific mechanisms? > > Regarding comment nodes, I think that to do it properly we should fix pubsub > > collections and put blog + comments nodes in the same collection. Using filters > > and prefixes for nodes is really ugly workaround, and we can end-up with > > comments node persisting while a parent blog has been deleted. > > Lets not over-engineer things there. > > I can hardly have proper support of Pubsub server side, even after years > of work. Asking to have those extra complexity is a perfect way to be > sure that I end up not having those feature before a few more years. That the reason why I've built a standalone, server independent Pubsub/PEP component (which does have support for collections BTW, even if I'm not using them yet). It's not over engineering to group a blog post and its comments or other linked nodes. The goal is to avoid "orphan" nodes, when you delete a parent blog node and the comments stays forever. But this can be done separately. > > However, 'pubsub#type' is not specified in XEP-0060 (only seen in examples), > > and it should get the namespace of the item payload, i.e."http:// www.w3.org/ 2005/Atom" in our case, so you should use (create?) an other metadata field to > > handle "profiles". > > No, we respecified pubsub#type exactly for this, because it was unclear. Well no, as of today (XEP-0060 v1.24.1), 'pubsub#type' is only cited in examples, and examples are not normative, so 'pubsub#type' is not specified. So it would be good then to add an appropriate section either in XEP-0060 or in a new XEPs to explain exactly what this field is supposed to do. So far, my understanding is that it is the expected payload type, i.e. the namespace of the first element, and it is primarily used for filtering nodes on disco request. > For 0277 I'd advise to define a pubsub#type that is actually > 'urn:xmpp:microblog:0' (there > https://xmpp.org/extensions/inbox/pubsub-social-feed.html#profile_microblog) > and not 'http://www.w3.org/2005/Atom' then I know that the node is > actually a bit more than "a Pubsub node with Atom items in it" and as a > client I can adapt my UI/UX to it. It makes sense, but it must be specified somewhere, and not lost in standard@ "advice" or in some random MUC. King Regards Goffi _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
