32100+ entries in 0.019s
diana_coman: open-ended lists like
that are always a mess and doubly so via messages
diana_coman: ugh, last
time
the rough sketch sounded as I said above
though, lolz
mp_en_viaje: nah! see, "what is armor of
the pigs ?" "well, it could be joes_armorofpigs.mesh or moes_armorofpigs.mesh or dyna_armorofpigs.mesh" and client is set
to get dyna* so continues "what is dyna_armorofpigs.mesh"
diana_coman: iirc it was specifically not a list of meshes but at most a list of overall graphical profiles as it were; i.e. each
thing
then at any
time has only one option
mp_en_viaje: imo much sounder like
that, for myriad reasons.
diana_coman: rolling back
to
the original
thing,
this is all
there is
to it: if c/cpp does not actually get
to ask for anything
then
there is no
trouble at all, sure.
mp_en_viaje: if you recall
the whole
theory with "give alternatives for gfx", server could in principle offer a LIST of meshes. possibly different qualities, and even same quality.
mp_en_viaje: this part is not avoidable
though, only user can
tailor
this sorta
thing. "how much space
to give cache and what sorta
thigns
to keep
there" is emintently
the function of config
mp_en_viaje: and so i suppose all
this can go in config file.
diana_coman: (re files and access
time I need
to look if I can get it, hopefully, via Ada.Directories)
mp_en_viaje: it's only
the user whocan decide "i don't want any sounds" or "no videos" or "no meshes only icons" or anything like
this.
diana_coman: but
that care is not "use" from earlier but..what?
diana_coman: but if it is
to ask of anything it doesn't yet have/know,
then it should ask for all of
them, it can't not care about some of
them
mp_en_viaje: ok, so
those it cares about it asks about and
those it doesn't care about it doesn't ask about.
diana_coman: it cares about
the object;
this doesn't mean it cares about ALL its properties
diana_coman: it asks for
the object;
the object descriptor includes
the properties; on
the principle
that "what client doesn't yet know, client will investigate further", it should ask for
them further,right?
mp_en_viaje: so if your client doesn't care about
them, it doesn't ask for
them, what's
the problem ?
mp_en_viaje: i mean, if client doesn't know wtf it is, how is client
to use it ? obviously it informs.
diana_coman: fwiw I'll clearly have
to hack my own client at
the very least for making it
text-only since
there's no point in asking for all
the graphical parts just because server did inform
that
those objects have
this and
that graphical part
diana_coman: so it needs now
to keep in addition a
timestamp on data access?
mp_en_viaje: well, if client sets a limit,
then oldest-used files get wiped.
diana_coman: from my pov I'm fine
to switch perspective and go
then with
this approach, so basically
there are no "client/cpp demands" anything since Ada-part directly handles it on
the principle "if I saw it and it's not
there,
then I'll ask for it"; how is any limit re space or anything of
the sort
to be defined and handled in
this case?
diana_coman: if client doesn't care about mesh , but it asks for it because it saw it, isn't
that in advance?
diana_coman: client asks what is a? server says it's (name
this) (position
that) (mesh
theother) and so on
mp_en_viaje: hence, imperative. once client decides
to print something, IT WILL BE PRINTED. no ifs or buts or lookups.
diana_coman: well yes, but
that's
the
thing,
the problem is not solved by asking in advance
diana_coman: "wtf do we put in
the press ?! " ->
the default.
mp_en_viaje: function of how much space
the user is willing
to give
the cache, client could indeed keep everything.
mp_en_viaje: the client does not keep everything in
the sense
that it's not required
to keep everything, not in
the sense
that it can be relied on
to not keep everything.
diana_coman: (and
this
thing
that "doesn't keep everything" is why I went with
the different approach aka ask when needed, not when heard of it)
diana_coman: the difference being
that client (as previously discussed) anyway does not keep everything so asking when it doesn't need it is not solving
that problem
mp_en_viaje: "now we're printing
this guy's helmet. wait, wtf do we put in
the press ?!"
diana_coman: how is it imperative?? server says
this guy wears
the helmet of doom; client says meh, can't be arsed
to show helmets; how is it imperative?
mp_en_viaje: similarily you look up new words when you hear
them rather
than when you decide
to use
them.
diana_coman: why exactly
though would client ask based on what server says rather
than based on what it finds itself actually needing
to use?
diana_coman: this bit here is
the part where we were not in sync
diana_coman: finally at least
the whole
trouble makes sense
diana_coman: oook; so
then, do you mean
that "asks for data" is
to be driven by.... what it receives from server rather
than attempted use?
mp_en_viaje: it's clear, one's in c
the other in ada, yes.
diana_coman: or you propose
that
this shouldn't even be
diana_coman: is at all clear
that
there is
this separation between
the client-part
that uses/needs some data on one hand,
the one I kept calling "client" or c/cpp and on
the other hand
the lower layer
that is protocol aware and actually "asks what is x"?
a111: Logged on 2019-05-28 09:13 mp_en_viaje:
the elegant solution for
this would be for
the client
to keep a list, "items
the server mentioned, we asked for but never received usable answer
therefore using a default", and either go
through it whenever convenient (eg, when player goes afk) or else even expose a button for player
to do himself).
mp_en_viaje: if it gets it, it uses it. if it doesn't get it, it uses
the default.
mp_en_viaje: client asks what is X, gets a response including data it doesn't have ; asks for
the data.
diana_coman: honestly, as a player, I'll
then have
to hack my own client, lolz
diana_coman: let me get
this part straight
though: how is
this "now" decided? every frame whoever has something unknown asks for it? some parameter every x ms ask for everything unknown?
mp_en_viaje: it's easier, and it's not clear
that
the complicateder way is in any sense better.
diana_coman: it does seem a weird problem
to have in
the simple sense
that honestly it's just easier
to do it as you say: no responsibility for
traffic, just shoot whatever and as many
times as higher level asks for... data, not for
traffic, but whatevers.
diana_coman: no, because it forces
the very same problem higher up where
there is even less information
to decide on when
to request
mp_en_viaje: if
there IS a queue, you can STILL get a new request just as
the queued request is satisfied.
diana_coman: what is
the gain in forcing every request -> a message
to server?
mp_en_viaje: looky : if
there's no queue, you can in principle get a new request just as
the old request was satisfied.
diana_coman: let's
take it from
the other end, maybe it's easier
diana_coman: it depends on what arrives and when + on
the contents of
the queue itself really since for instance a huge filename will fill a whole msg
diana_coman: I don't
think I get it and I'm not sure whether it's because some
things are still not right (for starters
there is no fixed duration as it's dynamic basically)
mp_en_viaje: it ~might~. you can not prove
they do, for all you know all
Ti come at L+e. how do you know it helps anything ?
mp_en_viaje: not anymore. anyway, looky :
take
the object icon.jpg.
the client may ask for
this item icon.jpg at
time intervals
Ti which, as far as we know, are random. now, if you have a queue, of fixed duration L, you offer
the guarantee
that "for any
Tjs
that are closer
than L only
the first does go
through".
this, you say, "reduces overal requests".
diana_coman: ugh; at least Internet used
to be working well in Ro.
mp_en_viaje: i have NEVER seen
this shitty internet in my fuckign life jesus
mp_en_viaje: dude
this piece of shit... it's showing your lines but not sending mine.
diana_coman: then I don't get it; because if it is
the client's decision
to ask immediate refresh
then sure, what's
the problem? it's
their decision and it still is
the minimum
traffic resulting
diana_coman: the point is not
to forbid
to
the client repeated request
mp_en_viaje: AFTER it
took it out of
the queue. immediately after.
mp_en_viaje: lol
this shiternet... im getting like 7 lines in a bundle.
diana_coman: or you mean a potential "race condition"
there?
diana_coman: otherwise yes, no point in having
the queues in
the first place really; a duplicate request can have at most
the effect of increasing counter of "requests for
this here object a" if one wants
then
to
treat
them as priorities basically aka ask first for
those items
that have been demanded most
times
diana_coman: i.e. client comes in
the shop and asks 100
times for
the same
thing while shopkeeper is working on delivering it so what
diana_coman: it accepts
the new request, looks
that it's pending so ..nothing
to do with it
mp_en_viaje: your proposal does not resolve
the
t4-t5 problem. having a pending queue does not mean
that
the client may not decide
to ask again JUST as
the "requester"
took
them out of
the pending queue.
diana_coman: move
those
three IDs* I should have said; not
the objects
themselves
a111: Logged on 2019-05-28 12:07 diana_coman: my proposal was
to have
the Requester ask "what are a,b,c" and move
those
three objects into a "pending" queue; when another request for
them arrives,
that's fine; when requester wakes up, it checks and prunes any
that meanwhile are
there so it doesn't ask again for stuff it meanwhile got
a111: Logged on 2019-05-28 12:06 diana_coman: and now re waste
traffic: at
t1
there are requests for obj a, b, c; at
t2 Requester wakes up and asks
the server "what are a, b, c", drops
those as "done" and goes back
to sleep; at
t3
there is another request for a,b,c so Requester puts
them back in its queue; at
t4 a,b,c arrive; at
t5 Requester wakes up and ...asks
the server again "what are a,b,c?" because well,
they are
there in
the queue, right?
diana_coman: only if it
throws it away without even using it, can
there be "no cache"
diana_coman: uhm, "no cache" is ...impossible; by definition
the data on client IS CACHE
mp_en_viaje: situation 2, cache (called "requester") : client will abstain from asking for some item for a certain
time after having asked.
mp_en_viaje: so, as
to
the matter of client cache. situation 1, no-cache : client wants some item, asks for it, potentially asks again before server has had chance
to answer.
mp_en_viaje: but let's resolve one issue at a
time, because
this is not working.
diana_coman: the default.jpg is not sent by server, no; local cache has defaults because it has
to - it needs
to use something before
there is even any answer from server; hence
the defaults part is not about
traffic at all
mp_en_viaje: i am not saying "there is no difference". i am saying "you are proposing
to produce a mechanism
to resolve a problem you imagine exists, such
that
the solution's parameters are populated by guesswork and
the imagined problem is not eliminated"
diana_coman: the point is not about "how fresh
the final data is" but rather simply
that: how many messages get generated for x requests
diana_coman: so you say
there is no difference between caller asking for it 10
times and
this resulting guaranteed in 10 messages
to
the server because requester does not keep
track of anything on one hand and on
the other hand 10 requests resulting in only 1 message
to server because requester does keep
track?
mp_en_viaje: not objectively fresher
than
they are when
there's no queue and
t4 comes around.
diana_coman: after
they resolved is however "refresh", isn't it?
mp_en_viaje: diana_coman, if
the server asked what's b answers no such
thing, use default.jpg every
time, you're sending default.jpg every
time.
diana_coman: uhm, while it still has
them pending or what?