XSF Discussion - 2021-11-11

Holger, I don't quite get where '413 duplicates anything with RSM, can you enlighten me?

(when you get the chance, anyway)

to me, it only extends PubSub (and '313 for soe rea

as I see it, it only extends PubSub (and '313 for some reason), it only has an example for PubSub+RSM+'413

jonas’: I didn't say it duplicates RSM. It extends it in the same way as '313 Flipped Pages.

how does it so?

Reversing ordering?

flipping a page is different from reversing the entire result set

Ah yes '413 _now_ does both (since the last revision).

I can't find it in the text, what keyword do I look for?

No I mean you're right, behavior is different now.

for the record: result set: A B C D E F, page size = 2, reversed ordering: [F E] [D C] [B A], flipped pages (non-reversed): [B A] [D C] [F E]

It makes no sense to me to have Flipped Pages in '313. But that's too late anyway. The thing that could still be avoided is the duplication _within_ '413.

AFAIK, '413 only does reversed ordering, not flipping pages, so there's no duplication with the thing MAM does (which IMO also only makes sense in the context of MAM, which streams its results instead of sending it as a single IQ stanza)

okay, and where's the duplication within '413?

(I'm asking because I just replied to goffi on-list and I'd like to make concrete suggestions for improval for '413 if there is anything wrong with it, so I was checking it based on your comments from today and I fail to find it; might be lack of awakeness in the early morning though)

My email on the list was unclear?

'60 basically has two mechanisms for retrieving item sets.

okay, so you'd move the '413 logic into the '59 element instead of the '60 element?

'413 extends both.

I still fail to see that in the text, sorry

oh

by both you mean both mechanisms in '60, sorry

I thought you meant '59 and '60

aha!

so you're saying '413 should drop the text for plain '60 retrieval and only support '60+'59

'413 example 4 vs. example 7.

Yes.

I see '60+'59 as a special case of plain '60 item retrieval, I think that's where my confusion came from.

so to me, example 7 is just a logical extension of example 4, not an entirely different thing. hence, no duplication in my mind.

Thanks for clearing that up for me :)

'60 even has some text that we "might recommend '59 in the future" or something. I'm just suggesting to do that now 🙂

Sorry I'm distracted and no good at explaining my point right now.

it's not you, it's me ;)

the only argument I'd have against changing '413 to become a generic mechanism only on top of '59 is that it feels like a potential premature overgeneralization and might lead to a generic standard which doesn't do anything completely right (which would fit with '60, mind ;)).

but thanks a lot, I get your point much more clearly now

FTR, that's the text I meant: > Note: A future version of this specification may recommend the use of XEP-0059 instead of the 'max_items' attribute. [ https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-requestrecent ]

Kev, I note that there is an exception of the "have to be new" rule: As an exception, returning GSoC Contributors may apply to the same organizations they participated with previously.

from https://developers.google.com/open-source/gsoc/faq

but yes the changes look good. especially since it is now possible to extend the deadline

I am not sure if I like the "have to be new" rule, especially since it is qualified by "non-trival changes"

jonas’, > the only argument I'd have against changing '413 to become a generic mechanism only on top of '59 is that it feels like a potential premature overgeneralization and might lead to a generic standard which doesn't do anything completely right I'd share that concern if I was suggesting actual protocol changes for turning a specific mechanism into something generic. My point is rather that the semantics are generic already, and just the syntax makes it MAM/PubSub-specific for no good reason. The thing that's not generic is the ordering criteria (the `by` attribute). (I understand how it might be easier to specify those within '413 as well, due to our workflows.)

To mention the '313 example once again (sorry), I'm totally not suggesting to come up with some generic filtering mechanism. It's just that flipping pages _is_ a generic thing as-is, and therefore it's wrong to have it in '313.

> flow escribió: > I am not sure if I like the "have to be new" rule, especially since it is qualified by "non-trival changes" can you elaborate a bit more?

well it the past it's been ok-ish if an existing project contributor became a gsoc student, even though gsoc always tried to incentivize new contributors (as opposed to "paying" existing ones)

however, incentivize existing contributors to work a large scale project, like adding some big new feature, for multiple months, is also beneficial for the FOSS ecosystem

especially since those contributors are already very familar with the codebase

now there is some rule that requires once to discuss what constitutes non-trivial changes (and what not)

dwd: does your security labels related libraries happen to have Lua bindings? ✏

flow: ok thanks. Then we should definitively review this for XSF as host

> well it the past it's been ok-ish if an existing project contributor became a gsoc student, even though gsoc always tried to incentivize new contributors (as opposed to "paying" existing ones) It's not been preferred though. I asked Stephanie directly about it a few years ago when we had an existing contributor apply (for one of your projects, I think), and she said it wasn't really in the spirit of it and we should put them at the bottom of our list and only accept them if we got all the slots we asked for.

So the spirit is "recruit new contributors" rather than "produce new contributions".

Holger: Yeah.

Kev: Thanks, then its indeed important to start early

Maranda, No, but it's straightforward C++, so should be simple enough to do.

dwd: ok 👌

It is a bit of a pain with resource allocation, though, I've wondered about including a cache management layer to make that easier.

dealing with MM is the part I wanted to exactly avoid myself considering time allowance to play with that stuff is what it is already unfortunately, but I'll give it a check as soon as time allows.

Holger, jonas’: (re: XEP-0413) it would make sense to put XEP-0413 in RSM as suggest Holger. I'm against removing MAM support and I actually think that MAM should be the defaut way of querying a pubsub service (I've answered to your message jonas’ with reasoning). I'm very busy now so I can't really follow closely this room, please send to standard@ if you have suggestions for 413.

goffi, thanks, will do

Yes, with PubSub-MAM there's a third item set retrieval mechanism. \o/

I never got the idea of PubSub-MAM, I'm out :)

jonas’: Full-Text Search on my blog (https://www.goffi.org/) is powered by Pubsub MAM

In case anyone is interested, next weeks office hours are an experiment to see if a virtual co-working hour would work. Feel free to show up (not the usual time) and hack on your favorite project, or just hang out! https://opencollective.com/xmpp-office-hours-virtual-co-working-hour-791e55a7

👍

Meeting time?

Serious question, I really don't know anymore

Sounds plausible :)

> 16:59:13 ralphm> Can't make it today, but +1 on proceeding with GSoC

I think this was in the wrong channel

Sorry, I'm hear but was miles away mentally.

Here, even. There's some proof. :-)

Yes 😴

https://fosstodon.org/web/@xmpp/107260354354538467

Sorry, my bad: You don't need to be a student anymore!

@all with access to the XSF twitter account: could you mimic the recent three on Fosstodon in the correct order in the Twitter account so that it is aligned? If you need help with the pictures let me know. https://fosstodon.org/web/@xmpp that would be a great support

ahh - wait - another post on its way ✏

Ok now its ready