Le 2021-08-09 02:08, Stephen Paul Weber a écrit :
My main observation about this proposal is that it attaches meaning to
otherwise-opaque var strings, and in general reads more like a hack
than a
solution. I am sympathetic to the need here, but I think we can solve
it
without resorting to this, and even still without needing to update
caps. Disco
and Caps already define a solid extensability mechanism as data forms
to be
included with the info. This proposal could perhaps look something
like this:
<iq from='example.com'
id='disco1'
to='example.org'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
…
<feature var='http://jabber.org/protocol/rsm'/>
<x xmlns="jabber:x:data">
<field type="hidden" var="FORM_TYPE">
<value>urn:xmpp:feature-attachments</value>
</field>
<field var="http://jabber.org/protocol/rsm";>
<value>http://jabber.org/protoco/pubsub</value>
<value>urn:xmpp:mam:2</value>
<value>http://jabber.org/protocol/disco#items</value>
</field>
</x>
…
</query>
</iq>
Thus anyone not implementing the XEP sees exactly what the do
currently, caps
will work unmodified, but anyone implementing the XEP can easily (and
dare I say
*more* easily) get the list of attached features to any given other
feature.
Hi Stephen,
Thank you very much for your suggestion, I find your proposal far better
than mine.
My proposition was a working base for a problem I want to see solved, so
if the protoXEP passes council (and if council member who have voted in
favor of it are OK with it), I can publish a new version using this
solution, and add you as an author.
We have been discussing this suggestion and protoXEP in general on xsf@
MUC room (unfortunately, I would have rather seen the discussions
happening here), and there were some useful arguments.
As I remember, the main points were (I don't necessarily agree with all
of them):
- disco feature string should be opaque, and my proposal break this by
doing a construction
- added complexity: my proposal is more straightforward to implement (we
just have to look as the attachment namespace to know if a feature is
attached to an other one), while yours must be done in two steps
- having a generic solution may bring non sense while attaching randomly
to features (e.g. RSM on MUC)
- it would be better to specify feature attachment directly on the
concerned XEPs (e.g. directly on RSM or Order-By)
In my opinion, your proposition is cleaner, takes elegantly profit of
data forms/disco extensions, and doesn't feel like a hack. I don't think
the extra complexity is a big problem.
I also think a generic XEP is needed to have a common syntax, and to
know if disco-feature attachment is implemented (otherwise we don't know
for older XEPs if a announced feature is implemented for it or not, and
some XEPs are in state which prevent namespace bumps).
Furthermore, having a generic XEPs explaining the syntax doesn't prevent
to mention it and to explain how exactly the feature is attached (e.g.
what does it mean using Order-By with Pubsub, and how to use it).
I would love to see feedbacks here, I think that the problem we are
trying to solve is affecting a couple of XEPs and many people are
concerned.
Thanks
Goffi
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
