XSF Discussion - 2020-05-02

flow, i think the reason against text-multi was that most librarys would join all values of a text-multi field

and not pass them as a list of text values

XEP-0004: ... Similarly, an application that receives multiple <value/> elements for a field of type "text-multi" SHOULD merge the XML character data of the value elements into one text block for presentation to a user, with each string separated by a newline character as appropriate for that platform.

and thats also what i would want from a xmpp lib, pass me one text string

its not hard to do a split(\n) afterwards of course

but not sure if this is more elegant than the <open> solution

lovetox, i am not sure if it is sensible for libraries to loose the "this are single values" information by joining the values together

I think the text is more meant for the higher layers, hence the "for presentation to a user" part

surely otherwise the usage of text-multi in pubsub would be problematic for users of libraries which do not expose those indivdual values at their interface

so what does smacks?

well, smack keeps the individual values

just as it does for jid-multi

or, fwiw, list-multi

yeah but you cant compare them really

why should a library suddenly handle, or especially implement, text-multi in a different way than the other *-multi

why shouldn't I be able to compare different types of form fields?

ok other question, if i set a text-multi field in smacks

do i have to pass a list of values?

no, there is addValue(CharSequence) and addValues(List<? extends CharSequence)

but all those append to the list of values

from an application developer standpoint, its not evident why i should split up a string on \n to send it over the wire

i want to pass a string to the lib and it should send it

right, but this is not related to the question

and on the other side i want my string out

i dont care about xmpp breaking up on \n and send it as multiple values

ahh, I guess the reason is newline portability

to use your lib, i have to understand XEP-0004, or you write a really good documentation where you tell me i have to join the string afterwards

so that could be the reason xep4 talks about "newline character as appropriate for that platform"

and at that point i seriously ask myself, why doesnt do smacks that

well it is a bit trickier

if the user ad addValue(CharSequence) with a CharSequence containing a '\n', shall I split it? or does the user want to send it as single value verbatim

but again, this is nothing which prevents us from using text-multi in mam

nobody said it prevents it

i told you what i heard when they discussed it

and that was one of the things i heard

so that is what I am interested at most right now, but I am also happy to discuss the text-multi newline UI situation if you want

maybe there are others, but from what i remember it was not a very drawn out decision process

no actually i dont care about that topic, i just wanted to forward my information

im sure MattJ is interested

but that is also pretty simple: the authors of xep4 basically had two choices: either normalize newline before it is put on the wire, or resort to what they did and split newlines into separte values (if the data is meant for user presentation)

I actually think I would have gone for the "normalize newline" thing, but this is what we have right now

i never have that problem

in my gui framework there is no thing as platform specific newlines

if i do a \n in a textview

its a newline, on windows and on linux

yeah, it was probably a different world when xep4 was written

its probably a problem if i would save the value to a textfile, which is opend by other apps maybe

IMHO an XMPP library should abstract XMPP, and application devs shouldn't need to be familiar with the representation of multiline strings on the wire

Therefore it is entirely reasonable for a library with a dataforms API to perform the newline splitting/joining itself