XSF Discussion - 2019-07-19

>tom, can you tell my corporate IT dept, they use all the proprietary blackboxes, riverbed, telari, cisco, and palo alto I think it's more of a leadership issue tbh. The places I've worked at, the CEO understood how to sell a product. They were not engineers. They paid engineers to make the engineering detail decisions. That understood that is; after the whole whole reason they are paying them for.

well, the CEO was more knowing how to lead all the different teams

because we did have a sales team and they did sales

and an accounting team which managed the money

the 'officers' acted as the glue

and were very good at it

and delegated things they were not good at to people who were

then again the product was IP transit, so the quality of the technology was the end goal

not just a means

hmm nyco not a huge deal but I don't think https://github.com/xsf/xeps/commit/6e1c4675714d80824f5f951a64c2d47e14deee4b#diff-48188c65e1a20d564eb9dbe110506a16 is correct either

> the document specifies to DO THIS

is what I meant, probably could be worded better, but two doesn't make sense there to me

maybe "This document specifies an algorithm to additionally look up records..." or "This document specifies a method to additionally look up records..." or "This document specifies a way to additionally look up records..."

moparisthebest, huh, you’re right

I need to revert htat

It somehow made sense to me when I read it, but it doesn’t

that DNSSEC vs SRV debate last night, was it based on Travis' email?

vice versa probably

oh, the timestamps

How could I have possibly missed the addition of a MUST NOT?

heh, most protoXEPs in the inbox fail at linking to the proper xslt file so the .xml link fails

Maybe we could also have a link to that file in the inbox

that would make sense

I submitted a PR

pep., against the nginx config?

ah, no I just added a symlink, just like there were already for the .ent and .dtd

against xsf/xeps

I see

https://bouah.net/2019/07/new-sprint-new-goodies/

pep.: I've answered to the reactions "thread" now

:)

Ge0rG: I answered your answer ;)

larma: I think you misread my mail. "Each reaction SHOULD contain a legacy reaction body" ;)

good points on Reactions and LMC, though.

I always disliked LMCs limitation to "the last message"

I am sure this could be changed, no? I actually liked your point about LMC

Actually, all except backwards compatibility

Reactions surely can define an exception to the strict LMC rule

even then, it's not an issue.

instead of a correction you see a new legacy reaction

legacy?

"new legacy"?

legacy reaction = body

Ok. Not for me, thanks :x

what's not for you?

Ge0rG: no I didn't misread your mail, my opinion is SHOULD NOT or MUST NOT have a body

If we do any business rules regarding body

A fallback body will render the feature unusable as long as there are legacy clients

And we all know that there will always be legacy clients :)

larma: your reaction seemed to imply you read it as "MUST have"

larma: I disagree. The lack of a legacy body will render the feature unusable.

having that feature will increase the pressure on legacy users.

I disagree with your last statement

Unless you make the fallback broken on purpose to bully implementations, (granted, one could argue 393 is broken and it might be good enough, but not everybody agrees with me on this)

pep.: the more important question is whether you agree with the previous statement ;)

I disagree as well

And I disagree in a more general way than just reactions

I mean I disagree with your statement ✏

pep.: I see you moved that back to the list. very good

yep

thanks, I'll write a response when I'm less busy.

I just noticed that there's not really an easy way to get an individual entry out of MAM if you already know its archive id. Closest I can find is requesting the item before/after the id I have, then request 1 item after/before that one, to get the item I originally wanted.

Lance: You likely want to go for the item before it. Going for the item after and then the item before that is prone to race condition.

Ah, yes

It works ok enough for use case of deep linking into history, if you also want +/-N additional messages of surrounding context

but i was tinkering with saving just the archive id in a pubsub item to do pinned messages

I imagine there was an assumption of "if you know the ID, you already have the message". MAM is not POP, and isn't a full DB system either.

yeah, that makes sense

Though a lot of folks do keep pushing (with some success) to have MAM just be a SQL dialect. It's harder to implement on things which don't have SQL indices and such.

i can resolve it pretty easily by letting my server understand a new custom form field

but this was a "Huh???" moment