XSF Discussion - 2017-11-11

Guus, Ge0rG: I tried to address some of your feedback as well as make the text clearer in places: https://github.com/xsf/xeps/pull/540/files

SamWhited: would it make sense to update the "last updated" timestamp? I was refreshing my page, waiting for the build to succeed by looking at that date...

Wow, so much constructive feedback on a Friday night. Breaking the problem space into pieces really pays off :)

Ge0rG: Thought it might :)

Kev: thanks for making me do it :)

Guus: oops, sorry, I haven't been pushing versions.

SamWhited: no worries. Perhaps something that could be automated?

Guus: I don't think it's really necessary in this case; generally I just ask authors to update it when they make a PR. I just didn't do it for this because it gets reset to 0.1 when accepted anyways and the old ones would go away

Oh, I was referring to the datestamp on top, not then version number

oh, my mistake

they're the same thing though

that's pulled from the last revision block, IIRC

jabber.org's cert expired 4 hours ago

is that iteam's server to manage?

Guus: no. The jabber.org server is not an XSF activity. That said. There is an overlap between the people running that server and iteam

I'll nudge Edwin

thanks

Hurgh. Finally implemented most of Message Styling, SamWhited - what a drag :(

didn't do the nesting

I'm still in the opinion that the amount of complexity in the XEP doesn't warrant the benefits. I expect that a good deal of devs will only do the easy bits, or will do the non-easy-bits wrong.

I'd drop the recursion/nesting, and potentially all block definitions completely.

_that said_: *yey styles!*

(the other way around - the benefits don't warrant the complexity - but you got what I ment)

Guus: complexity? My parser (including blocks and nesting) is less than 50 lines

And that's Java with all its boilerplate

how do you tolerate java btw? the boilerplate is so annoying, I can't stand it

daniel: is it easily exportable into other Android projects? 😁

Ge0rG, i've been meaning to put this into an actual library. but you could already copy paste two class files and then have a static StylingHelper.style(Editable editable)

https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/utils/StylingHelper.java

public static void (c)

zinid, it's actually gotten a lot better with Java 8 (which you cant use on Android but i use that for my other projects)

plus IDE takes a lot of the pain away

I need to look at it then, I have heard java 8 has some improvements

daniel: great! But please make it a library... I always wanted to have one that would convert xhtml-im into Android Spannable, but I suppose I can give up hope now

yeah i like it a lot. even my seeminly small tools like the complinace tester or the uptime monitor (status.conversations.im) are java 8

i very rarely use so called scripting languages

zinid: can confirm Java 8 makes a huge difference

That bad? How did you implement it? I just recursed into the blocks and it was fairly easy

/cc Guus

SamWhited: You just used the words 'recurse' and 'simple' in one sentence.

What? It made it very simple

It meant I didn't have to special case the stuff inside blocks, just call the parse function again

Recursion is inherently complex. Not MUC complex, but a lot more complex than should be needed to print a couple of words in a bold font.

I wonder how many levels of recursion one can get into a single message

What stack size limits do you have?

Ge0rG, not that many actually. because limited keywords

I didn't bother setting one, the stack is cheap so if you want to send: > >> >>> >>>> Up to the limit your server allows for body size then be my guest

daniel: only if you prevent recusing into a keyword type that's already on the stack

i mean you couldn't just write *_*_*test*_*_*

thats invalid syntax

Oh, I didn't do recursion inside spans, that was simpler

You could add letters and whitespace?

What, can't have bold */and/* italics?!

Ge0rG, true

Zash: that should work

If you'd use underscores instead of slashes.

SamWhited: without recursion?

Bold *_and_* italics.

Ge0rG: yes, I think so. Let me clean this up and push it

or maybe not. i'm confused

Daniel, I think that there's a small omission in the preformatted block ending in Conversations

Guus:?

it appears to end on any occurrance of ```, instead of on a line that only contains ```.

This should not be monospaced. ``` if ( foo.equals( "```" ) ) { // This should be monospaced (but is not in Conversations) } ``` again, no longer monospaced.

ah, I see that the same applies to the start

Yes I think that got changed recently in the xep, right? I didn't follow your discussion yesterday

not sure, only worked on that today :)

Yah, I just tried to clarify that block, I think it makes it a little easier if you can just scan line by line.

but it stands to reason that ```this should not be monospaced``` (although `this` should).

The way I wrote my version having the ``` (which is the start of a block) inline means blocks overlap though, which ends up being way more complicated

but I could go either way

Fwiw in whatsapp triple back ticks don't need to be in their own line

Haven't check slack yet

I'll go do my grumpy old man routine in front of the tv. Will lurk on mobile for a bit.

I don't really care. It's a simple fix in my parser to only allow it when it starts with a \n

but could go either way

I usually just pastebin stuff I want to show

Spoiled by mod_pastebin mayhaps

how does the ignoring part go along with the first section where it says that keywords should stay in there?

Are, and if, how are, new lines defined in <body/>/XMPP?

daniel: good point; maybe I should change that to read "it's part of the keyword, not the preformatted block"

Flow: \n

SamWhited, great, where is that specified?

Flow: I don't follow, that's just a newline… I didn't mean literally typing \\n

Well strictly speaking \n is just a line feed

Oh I see, are you worried about people sending \r\n?

I have no idea if or where that's specified

Even more worse, a line break convention that doesn't end with \n

I wouldn't worry about it too much.

Maybe XML specifies a line ending to use? I have no idea. As far as styling is concerned that's deliberately handwavey though.

Well if we don't have it specified, and if a XEP speaks of newlines, then it should be specified to be sound

I wouldn't count on \r\n surviving exactly like that all the way across the XMPPnet

My XML decoder appears to normalize to \n

Zash, within <body/>? Any sane XML parser would not touch element text.

Changing everything to \n seems perfectly sane to me

But I'm still not sure if everything does that, maybe that's just this one

https://www.w3.org/TR/REC-xml/#sec-line-ends

IIRC we looked at having Prosody preserve all kinds of whitespace, and everything broke.

Thanks ralphm

There we go then. That explains why this has never been an issue in any XMPP clients I've ever used.

"MUST behave as if". I wonder what that is supposed to mean. But yes, looks like that any sane XML parser is supposed to normalize line endings to \n. XML 1.1. converts even more to \n

There was something that at least Prosody did to whitespace in some places. Maybe attributes? I forget.

Zash, maybe the whitespace between attributes?

Yes but no, that's not what we were looking at.

https://hg.prosody.im/trunk/rev/6e67c73f730c https://hg.prosody.im/trunk/rev/9030b056bd4a

https://www.w3.org/TR/REC-xml/#AVNormalize

Well, XML 1.1 is much too newfangled for XMPP.