Le 02/11/2022 à 18:12, Goffi a écrit :
Hi edhelas, thanks for your feedback
Le mercredi 2 novembre 2022, 13:21:01 CET Timothée Jaussoin a écrit :
I think its still valuable in some cases, especially for compatibility
with external tools that wants to import/export Atom items also I'd
prefer to not break any compatibility with Atom.
I agree about maintaining compatibility, as long as we are based on Atom, we
have to keep this text version, even if it's using bandwidth for nothing.
Great :)
- what is this "Gallery profile" thing ? It looks like a terrible way to do
photo galleries, ignoring all the work done by stuff like XEP-0447. Please,
I
see no good reason to have this.
The goal is not to replace or have "two-standards". This Gallery profile
is a way to ensure that the node is having at least one attached picture
to all the items, allowing clients to display it using a specific layout
(a grid for example). This would allow to have Picture based social
feeds such as Instagram etc...
I still don't think that it's a good way to do this: here images are just http
links, while with XEP-0447 we can associate links and/or jingle and/or
whatever with all metadata and thumbnails needed, and it's possible to add a
way to link a blog post to images.
Again, this is pure metadata and a way to help clients to see how they
should handle the node. And again, I don't see why we can't have both
way of supporting pictures in the same item.
I am handling pictures in Movim this way for close than 10 years now,
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.
The goal of this XEP is to pose the bases of "what is a social feed" in
XMPP and the core of it relies on pubsub#type (I asked the support in
ejabberd there by the way
https://github.com/processone/ejabberd/issues/3914).
The idea would be next to add a few more XEPs to define maybe other
pubsub#type from that one and to see how they can be handled
client/server side. For example we are thinking of adding pubsub#type
based filters in Pubsub services. That would allow clients to only get
the main article-nodes, comment-nodes, galleries-nodes etc... based on
their preferences and not retrieve everything and then filter client
side (it is one of the big performances issues that I have right now).
'pubsub#type' would be"http://www.w3.org/2005/Atom"; in any case here, I don't
see how you would use it to get comment nodes or gallery node. You would have
to add an other metadata for that (which can be done).
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.
I didn't specified any Comments section in this XEP for this exact
purpose, keep things simple and straigtforward.
The goal of this XEP is basically to specificy a properly a generic way
of having social feeds on XMPP Pubsub (PEP or services) and ensure that
I don't end up with this weird "it's Microblog but not really" thing
that I have already for years.
The purpose of using pubsub#type and those Profiles is having a simple
way to declare and use nodes that can fits the different types of social
feeds that we see nowadays (Microblog like Twitter or Mastodon,
gallery/pictures based like Tumblr or Instagram, news-based like
Facebook or LinkedIn...).
Regarding the link with XEP-0447: Stateless file sharing I don't see why
<file-sharing> can't be used with this XEP. I can try to adapt the
'urn:xmpp:gallery:0' to gives the choice of the implementer on how he
would like to attach this mandatory picture per item (having two
examples, one with a '<link rel=enclosure/>' and another one with
'<file-sharing xmlns=urn:xmpp:sfs:0>' for example :) ).
Then you would be mixing atom and XEPs material, it doesn't feel right.
I believe that we need a proper protoXEP to handle photo galleries, probably
something like XEP-0214 but with XEP-0447 payloads instead.
We are already doing it, it is definitely not an issue to embed other
namespaces within Atom, Geotagging for example
https://xmpp.org/extensions/xep-0277.html#geotagging
That's the exact purpose of XML, complete features next to or within others.
You have plenty of other examples in chat <messages/>.
This XEP 'urn:xmpp:gallery:0' is about defining a "social feed that is
containing at least one picture per Atom item". I'm sure that the
gallery XEP that you are talking about might be a bit more than that
(having folders, some user restrictions etc).
But if it creates too much confusion I can remove that Gallery section
from the XEP and let you write a specific XEP for it if you prefer.
I don't really like this gallery thing because it will set an ill-conceived
precedent and when we come up with a proper photo gallery protoXEP, we'll end-
up with 2 competing specifications (which is the plague of XMPP).
Again, it is _NOT_ a way to enforce it. The pubsub#type is JUST a
metadata that is saying "hey client, this node items are having at least
one picture in them, you better prepare your UI/UX to adapt to it".
As Tedd Sterr said, I can change the name and call it showcase,
exhibition...
I can bring other social examples like this, we could have
'urn:xmpp:video-streams:0' that is enforcing at least one video file per
Atom item or 'urn:xmpp:stock-ticker:0' that is having a specific node
configuration with a <stock-ticker> item value that is updated each few
seconds for example.
Movim has been for more than 10 years in a weird state where I was
mostly based on 0277 with "hacks" to extend it outside this scope of
Microblog.
Despite its name, XEP-0277 supports normal blogging and blogs outside of PEP
out of the box, no need for a new XEP for that.
Yes, specified there: https://xmpp.org/extensions/xep-0277.html#location
And it is not clear how I can differentiate a Pubsub node that is
"Microblog" that is not located in a node id "urn:xmpp:microblog:0'.
This Pubsub Social Feed clarify this and said "all the nodes specified
under the pubsub#type 'urn:xmpp:social:0' have Atom item in it AND have
this specific Pubsub configuration" by default, there is no way to guess
that from 0277 nodes (maybe for PEP ones, but not for Pubsub services
hosted ones).
This XEP is a step ensuring that everything that is done is
fully standard and setting the bases of some future extensions in that area.
what is done currently is standard XEP-0277. But whatever, I'm not against a
new XEP with some extra stuff like node configuration etc.
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.
The namespace of the item payload is specified... in the item payloads.
pubsub#type is a way to have a metadata on the node that is giving you
both information about the namespace of the items (if there is one) and
the node configuration, exactly as it is specified in
https://xmpp.org/extensions/inbox/pubsub-social-feed.html#profile_base.
When a developer is then seeing a Pubsub node with a specific
pubsub#type it can check the related XEP to see how the node should
behave (regarding the namespace of the item content, the default
configuration, the handling of the items clients or server side...).
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.
Also, your proposal is using verbatim stuff from XEP-0277, I believe that
original XEP-0277 authors should be quoted somewhere inside your specification.
True, good point
King Regards
Goffi
_______________________________________________
Standards mailing list
Info:https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe:[email protected]
_______________________________________________
Thanks for the feedbacks,
Regards,
Timothée aka edhelas
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
