XSF Discussion - 2019-02-11

jonas’, http upload (XEP-0363) has LC ended, but it's not reflected in the document

jonas’, is it a known issue?

zinid, yes

ofg?

kind of ✏

I had no weekend and am back at work, don’t have the energy to look into this now

sure, just checking the condition of our xeps :D

I think there is a vote on the LC result pending for council, but I’m not sure

dwd ^ do you know?

HTTP upload... I can't recall the current status, but its last call brought up some security issues. I think those have been addressed, but I can't remember if we've done anything since.

I'd like to enforce Pubsub nodes to return their access model in their metadata, goffi what do you think ?

if not it's impossible for a client to know what to do/display when requesting a node

access_model and publish_model

it's a small change for 0060 but it will greatly help for the clients to display properly things in their UI

PR against 0060, see what council says :)

will do

While I'm happy for you to work that way if you want, it's a somewhat expensive way of saying "What do you think of the idea?".

the standard way for ""What do you think of the idea?" is to post to standards@ and not receive any responses, right?

Correct

:)

No responses, no objections!

Zash: speaking of which. How's the GC1.0 removal going?

Ge0rG: From spec or code?

Zash: from spec

Ge0rG: I did the same thing you did, realized that it was a larger task than initially expected and gave up half-way

Zash: we should have bundled our efforts

OTOH, it is good to be independently confirmed in my conclusion

We could have given up twice as fast!

I like how we're optimizing failure here!

I prefer to discuss a bit before making a PR, so you know more or less if you are on the right path

Regarding GC1.0, there was a discussion on standards@, and some Council member proclaimed that they wouldn't oppose removing it if it doesn't make things worse.

Seve: the issue is that you often don't get an answer :p

However, this is a very subjective matter. I've come to the conclusion that a MUC treating a presence update as a join and flooding me with message duplicates is worse than being dropped off properly.

Sad

Seve: Probably because most people don't bother replying with "Meh" or "Sounds fine but I don't really care about this that much"

Ge0rG, Zash: If there where a git with the current state of your GC1 removal, people could and probably would collaborate and help (at least I would had a look too)

flow: that's exactly the problem. We both started at the paragraph first mentioning GC1.0, tried to remove it and realized that it needs to be written from scratch.

If somebody had started removing the protocol pieces instead, things might move forward faster

I am not sure how that problem keeps you from creating a git where people could collaborate?

I would even offer my repo, which would automatically create HTML diffs to the current xep45 version

(assuming the html diff tool is able to deal with xep45-sized xeps)

flow [10:50]: > which would automatically create HTML diffs to the current xep45 version Can we have that functionality please? Not as SaaS, but for use everywhere and anywhere?

flow, Zash: https://github.com/ge0rg/xeps/commit/11bf5c82fba0f46eb6e5560213d508fea4941396 (branch xep0045-kill-gc1)

Ah right, this problem > Compliant multi-user chat services MUST accept [Groupchat 1.0]

Zash: prosody 0.11 is incompliant!

IIRC there was consensus that it's ok. And while I am a strong supporter of namespace bumps on incompatible changes, I'd also simply remove GC1 without an bump

flow, Ge0rG: https://github.com/ge0rg/xeps/compare/xep0045-kill-gc1...Zash:xep0045-kill-gc1?expand=1

excuse the whitespace

Zash: you probably should also around some more, because now the first thing you see in the section is the error response.

should *move* around

Didn't I move that?

I'm sure I moved that up

ah, of course, that's not committed

thanks git

(and ralphm)

ralphm: thanks

updated the thing

Kind wondering: should the id attribute of the error stanza match the original?

Kinda

Oh, never mind, the error response doesn't have an example of the original stanza.

Ge0rG, Zash: http://geekplace.eu/xeps/xep-muc-no-gc1/diff-side-by-side.html

That's a convenient tool! It'd be handy if it had a 'go to next change' action.

oh wow that's cool

very nicey

(Also scrolling down MUC takes some time..)

that's nice yes, could be nice to navigate directly to the changes

edhelas: I think enforcing would need a namespace bump which is not really possible seing the current "draft" status of XEP-0060, but with a SHOULD instead of a MUST it would be a nice addition. Probably trying to do a PR and see what council say is a good way to move forward.

flow: that's awesome, at least on a 1920x1080 display :)

now even with colored xml diff for the brave: http://geekplace.eu/xeps/xep-muc-no-gc1/xml-colordiff.html

flow, http://geekplace.eu/xeps/xep-muc-no-gc1/diff-side-by-side.html can you make it so that it uses the full screen width?

it’s annoying to read even on a large display

jonas’, I can do whatever https://github.com/cygri/htmldiff can do

I don’t know what htmldiff can do

you probably know that better than I do, given that you’ve set it up

The point is that I only use a python tool to generate the diff, and I don't know what the tool can do besides producing the output shown. From a quick look, the answer is probably "no"

That color diff HTML shows as xml in my browser.

Ge0rG, because it’s a color diff of the XML

I was lured by the .html file ending.

Yeah, don't view source on that :)

I just tapped the link 🤷

that is why I wrote "for the brave" :)

awaiting your GC1 removal PRs in case you want to collaborate on that

I really wish I could see diffs of the changes, instead of reading the revision history in the XEP and wondering what happened

In the end I'm reading the git version in the xeps repo anyway

pep.: yeah, a rendered diff version, even side-by-side, is a huge help for reviewing PRs

Ge0rG, I meant in the XEPs themselves

pep.: we used to have that

https://xmpp.org/extensions/xep-0045.html#appendix-revs this is useless to me

before The Big Crash

I see

We had a renderer that produced an inline-diff based on two revisions of a given XEP

It used to be like this: http://xmpp.org/extensions/diff/api/xep/0325/diff/0.2/vs/0.3

flow: how many hours of CPU time does htmldiff consume for 0045?

Ah! > htmldiff build/xep-0045.master.html build/xep-0045.html > xep-0045.diff.html > 393.65s user 0.12s system 99% cpu 6:33.83 total

fast, efficient

just like you'd expect from python

Ge0rG: And you haven't borrowed Link Mauves toaster?

model name : Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz

hardware is cheap nowadays I'm told, just upgrade

It's running on a single core. You can't get cores an order of magnitude faster than that.

And even then it'd still be slow.

do you mean to say that I cannot just by more CPU? o_O That's strange :/

*buy

I'm also told that Python's GIL is not a problem at all

python taliban is funny

just wait for Link Mauve to rewrite it in Rust :D

WLMRIIR is the new RIIR

it's better because then *we* don't have to do any work

But it will be full of race conditions!

just lock everything

Launch 200 instances of the process and accept bets on which will finish first

Launch one on each paragraph.

https://cerdale.zash.se/upload/eW2Xm7GsFtjj6AGW/killgc10.html

Not as pretty, but took 2s

speak of the devil look what someone just sent me :) https://github.com/konchunas/pyrs "Python to Rust transpiler"