Flo, I think you’ve carefully (and silently) snipped out the most relevant half of my message, so I repeat what I said before.
1) I think we can not reasonably update XEP-0004 to change the meaning of text-multi at this point (and, as I said, it is not clear to me if anyone is suggesting that or not). 2) If XEPs want to change the meaning of text-multi for specific cases in a negotiated scope, they can do so. i.e. (2)-> if MAM uses text-multi differently, in MAM-namespaced queries, it’s reasonable to do so. This is consistent with what XEP-0122 does in allowing <open/> to change the semantics for list-multi/list-single that were defined in XEP-0004. It would be functionally equivalent to saying that MAM uses a text-multi field with one id per line. /K > On 13 May 2020, at 13:50, Florian Schmaus <f...@geekplace.eu> wrote: > > On 5/13/20 1:50 PM, Kevin Smith wrote: >> On 13 May 2020, at 03:40, Peter Saint-Andre <stpe...@mozilla.com> wrote: >>> <snip/> >>> We might want to face reality >>> and allow text-multi to treat each line as semantically independent. >> >> Sadly, I don’t think it would just be ‘facing reality’ to say that >> text-multi isn’t multi-line text - there are implementations (every library >> I’ve worked with, I think) that treats text-multi as a multi-line string >> (i.e. in support of what xep4 requires). > As soon as such a library where to implement e.g. PubSub collection > nodes, it has to expose the individual values of a text-multi field in a > robust way. And it is not like doing so would mean that you have to > loose support for what xep4 requires. > > Because surely those libraries could be easily extended to expose the > text-multi values, in addition to a single multi-line string, as a list > of strings. > > >> I am sympathetic to the argument that we’ve gotten into a mess, but I don’t >> think getting out of it (given that 4 is Final) would be as simple as xep 4 >> changing semantics for text-multi - it’s not clear to me if that’s what >> being suggested, but if it is I think it would be painful. > > I do not see where we change the semantics of text-multi here. > > XMPP (and protocols in general) often gets criticized for being > over-engineerd and complex. And, while I do not like those who scream > "over-engineerd and complex" every two seconds, this discussion appears > to be a prime example what can go wrong. > > We have currently two options to carry multiple values from A to B in > xep4 data forms: > - one that requires one XEP > text-multi: xep4 > - another one that requires *two* XEPs > list-multi + <open/>, xep4 + xep122 > > Obviously text-multi, requiring only one XEP, is desirable. In fact, it > so natural that existing XEPs and ProtoXEPs in inbox/ use it for exact > that case. > > Yet, there are attempts to argument that text-multi can not be used > because of some implementations do not allow for it. But I fail to see > how that can be an argument: implementations can be adjusted. > Furthermore, it appears *trivial* to extend those existing > implementations to allow for it. And that would not even break backwards > compatibility, and hence does not even need to be negotiated. > > Fields of the type text-multi contain as a list of textual values. Even > if the initial motivation was to allow for portable multi-line strings, > I do not see any reason why we should not continue to use it to > transport multiple textual values (e.g., the IDs of the MAM messages we > want to retrieve). > > MAM currently is a shining star of a reasonably well-designed and simple > protocol. I hope we keep it that way. > > - Florian > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
