tmsr - Log 2019-05-27

diana_coman: in other stepping-in-all-the-holes : it seems I found a fail-mode of mp-wp browser interface namely if one pastes the content of a post first and only then (possibly after it rushes to quick save it or whatevers) the title, it fails miserably as it apparently tries to save it with title "" (notwithstanding that no, it should not, there is actually a title to it) ☟︎

mp_en_viaje: diana_coman, cluj

mp_en_viaje: speaking of which, if anyone is in the area and wants to meet, speak up, i'll be around for a few days

mp_en_viaje: diana_coman, no, it saves it with a numeric title.

mp_en_viaje: you can edit the slug if you want later

mp_en_viaje: me either, but what can you do.

mp_en_viaje: can't what, save ?

diana_coman: so apparently the numeric title is borked or at least borked on my installation

mp_en_viaje: sounds like borked install. what's preview do ?

mp_en_viaje: doesn't preview, either ?

mp_en_viaje: what you describe specifically was debugged ; i suppose entirely possible php/whatever stack versioning shenanigans may have managed to regression it, like that insane case we ran into recently with the comments not working

mp_en_viaje: but in principle should not fail in any combination.

diana_coman: ugh, now ofc can't quite reproduce it i.e. it was something more subtle than what it seemed...

mp_en_viaje: well anyway, regardless of implementation, the design idea there is that article title always has a ready gensym in the shape of the numeric id of the table entry, which is unique and always known and therefore should be the fallback default.

diana_coman: that makes perfect sense and is pretty much what I'd have expected; hence the surprise earlier when it apparently refused the title and insisted it was ""; anyway, if I run into it/something else again I'll document it better on the spot I guess.

mp_en_viaje: ]there;s also a js autosave if you have js enabled in browser ; these may have interracted weirdly i guess.

mp_en_viaje: js is fucking impossible to debug.

mp_en_viaje: (there's also a js doing wordcount on pressing enter, and a few other sugar cubes like that)

diana_coman: I quite suspect it is the autosave thing because this much I remember that it was after it auto-saved, hence my suspicion at it; but at least atm it the autosave did not fire and tbh I'm not extremely keen on chasing this right now.

mp_en_viaje: let's leave a breadcrumb for billymg, too, whynot.

mp_en_viaje: diana_coman, speaking of http://ossasepia.com/2019/05/27/euloras-client-core-the-dedicated-requester/#selection-41.2-41.111 i don't see the wisdom in this position. suppose your client sees a new type of whatever, and manages to get everything but the icon. a) your path would require it to die trying but b) evidently going ahead while using a ~default~ icon until gets a better one is perfectly acceptable.

mp_en_viaje: in limine, an eulora client which plays with 100% default data objects, everyone-is-an-axe-cutting-axes-with-axes-on-axe-planet is a-ok.

mp_en_viaje: why not ?

diana_coman: because the requester does not request "x and y and z of 187" ; all it requests is "187" and then it simply checks in EuCache: do you now have 187? Now WHAT EuCache has for 187 is not something requester can know in advance

diana_coman: I suspect I'll need to detail the data model too for it all to make sense

mp_en_viaje: sure. now suppose client asks for 185, 186, 187 and 188, and gets them, within an hour.

mp_en_viaje: should game be unplayable for the hour ?

diana_coman: why would the game be unplayable for the hour? for one thing: why would the game be unplayable at all at any moment anyway?

mp_en_viaje: cuz "die trying".

mp_en_viaje: either it dies, or it doesn't die. if it dies, you can't play it. if it doesn't die, it somehow manages to make do w/o the item (ie, uses defaults)

diana_coman: die trying aka after x successive timeouts (timeouts aka NO data received in the whole interval*x )

mp_en_viaje: i do not believe it should die at all.

mp_en_viaje: imo it should try ~once~ per mention.

mp_en_viaje: every time the server mentions an object it doesn't have, it asks for it. that's it.

diana_coman: uhm; on one hand the "does it die or not" is a tiny thing i.e. it is a decision of what-do if not received;

mp_en_viaje: i'm not even sure it's worth producing the retry mechanism.

mp_en_viaje: logically speaking, if it's unimportant it's unimportant ; this is a game world criterion your retry cache can't figure out.

mp_en_viaje: how do you mean /

diana_coman: the ~only consideration is perhaps whether to re-include whatever it hasn't yet received or just drop them and if they are demanded again then they'll make it again another time

mp_en_viaje: in the capitalistic perspective : if 100 objects are mentioned 10`000 times and requested 10`000 times, then i'd like the one object mentioned 1`000 times be requested 1`000 times and the object mentioned once be requested once.

mp_en_viaje: this seems the correct capitalistic split of the request pie : by mentions. rather than "everyone gets 100"

diana_coman: something still seems rather mixed in there; let me see if I can untangle it

mp_en_viaje: mentioned means the client sees an object it doesn't have in a server communication.

mp_en_viaje: ie, if 10 people go on a raid and 5 of them wear armor of the stars, said armor will be mentioned by server 5 times.

mp_en_viaje: well, cuz client may well discover "shit, i never heard of this armor before, wtf is it"

mp_en_viaje: well presuming it doesn't get it.

mp_en_viaje: whole discussion is predicated on comms failure, client asks but doesn't for some reason get.

diana_coman: yes but there is no generic client asks as such; from pov of client ALL the asks always get - defaults.

mp_en_viaje: as a fall through you mean ?

mp_en_viaje: let me model an interaction to make sure we're on the same page here.

diana_coman: as a higher-level concern than Requester's ; requester is specifically concerned with trying to get whatever is asked of it *from the server*; it can of course decide on what it requests first for instance (perhaps the item that was demanded of it most times since last request)

mp_en_viaje: so, server tells client at t1 "and then you came upon five persons, a, b, c, d, e, f".

diana_coman: and it can also decide on what to do on timeout e.g. drop that item and if it's important it will be demanded again hence it will make it into another request and if not , no

mp_en_viaje: client notices it doesn't know wtf these are ; so at t2 says "what's an a ?"

diana_coman: so a-f are data and therefore stored in cache as such; there are those things a-f ; nothing more

mp_en_viaje: and at t3 server replies : "a is a so and so and back and forth... and on his chest wears the armor of the stars, and bla bla bla".

mp_en_viaje: at t4 client continues its inquiry, "what's a b ?" ; at t5 client notices it doesnt know wtf such an armor is, so asks sefver "what's an armor of the stars ?"

mp_en_viaje: at t6 server replies : "b is a so and so and back and forth... and on his chest wears the armor of the stars, and bla bla bla".

mp_en_viaje: at t7 client decides "well, wtf, it's an armor, so ima show a wearing default armor, and whatever"

mp_en_viaje: then at t8 client notices AGAIN "hm, i'm using default for this armor of the stars, wtf is it ?" and asks the server again.

mp_en_viaje: but because an item it uses a default for is mentioned again, not because of any retries.

mp_en_viaje: at this juncture, if it finally gets a workable armor of the stars, it dresses both a and b in it ; but if not, whatever.

mp_en_viaje: it doesn't die nor does it retry. just plods along.

diana_coman: myeah, this "asks again" is not "asks the server" but "ask the requester" ; i.e. "client" does not directly talk to the server from anywhere because that is how mess is made

mp_en_viaje: alright.

mp_en_viaje: that part is fine, "client asks server through its dedicated monopoly on askings"

diana_coman: yes; and the requester (this dedicated monopoly on askings) will pack and send specific requests: server, what is an armor of the stars and a sword of the pigs?

mp_en_viaje: but if it's not happy with theresult, not only does it not die -- it doesn't even retry.

diana_coman: you mean if it timeouts on a request then it lets it just lets it be? it makes it even simpler from my pov, not as if it's an issue but essentially I'm not sure how do you then avoid the case where you play happily offline and ...not notice it? ☟︎

diana_coman: at which point recovery is a bitch way worse than restart; I suppose the point might be "don't die, just make it clear there's nobody answering "

diana_coman: anyway, if it shouldn't even retry the correct way to put it is that it doesn't *care* at all about the result; i.e. it sends the request, it goes to sleep for timeout interval and then when it wakes up it simply makes and sends the next request, without any care in the world re anything ☟︎

diana_coman: while this has the advantage of being very simple indeed, all it does in fact is that it pushes the complexity a bit higher up at the added cost of a lot of waste traffic ☟︎

diana_coman: if that armor of the stars is requested once then it's wanted *anyway* so what's the point in not tracking it where the request is assembled and instead having it tracked through repeated requests; after all this "oh, still not have it" is anyway still a look "is it in the cache now?" just that it's pushed higher up ☟︎

diana_coman: basically I don't actually think that "needed 100 times" SHOULD translate into "send 100 requests to the server" ; something is either needed or not; it might be more needed than something else, sure but that's a relative (and changing) ordering of requests at most, not a traffic-generator essentially. ☟︎