 | | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Timestamp because the server would need to know at what time the client last asked for the ratings. Changes since a given message number isn't sufficient because it provides too little information -- it would end up having to report back more (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Oh! I am thinking of "rating" as the number displayed with a message on the web site. Are you saying that you'd spit out the entire rating history of the message, for the client to do something with? Hmmm..... (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) I guess the client doesn't really care about the history of the message rating, but that would be the best way to adjust the clients view of messages rating... though I assume the client will be able to query the ratings of a message (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) All I really want is a number representing the current cumulative-to-this-point score -- like what's displayed on the web page. (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) I think you'll be able to get that from the message headers, when you look it up... but most cases the message when you read it first will have a rating of 50 - assuming you get it as soon as it's posted, no one would have had a chance to rate (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Hmmm -- is that a planned feature? Current messages don't seem to have an X-Rating (hmmm, that sounds kinda funny) unless I am missing something. (Always possible!) Anyway, that would be plenty good for me. 1) I don't tend to keep my (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) As far as I know (haven't checked in the past 5 hours) it's not there yet - but Todd mentioned adding it to the avid.cgi at some point. (...) nod, that'll work for you. For what I'm planning to do, the spooling process will run all the time, (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Me too. (What did you think I was thinking about?) (...) Yeh. For streaming clients, so they can update their ratings in an extremely time and bandwidth-efficient way. --Todd (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) A set of data resulting in that number. (...) Yah, the picture is becoming clear. I don't (yet) want anything so sophisticated.... (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Yeah -- what Dan said. I don't mean to send the entire _history_ with all the timestamps, but rather to send the raw data up to that point -- all the raw values -- (which is almost like the whole history) -- so that the client can calculate a (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
Todd Lehman wrote: [snip long good explanation] (...) nod, exactly what I meant. I was afraid you meant something like: lugnet.foo.bad:5321 80 lugnet.foo.bad:5321 40 lugnet.foo.bad:5321 70 lugnet.foo.bad:5321 50 lugnet.foo.bad:5321 -80 (a rating of (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) That number doesn't actually exist anywhere until display time. That is, the initial 50 is never stored anywhere, and won't be reported to clients. It'll be up to clients to add in the 50 or whatever value they choose for whatever group(s) the (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Yup, that's what I mean. It'll be up to the client to calculate the ratings from the set of raw inputs for each article. --Todd (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Uh oh; now I'm confused again. I thought articles were rated, not groups. Assuming that the above represent articles ("lugnet.foo.bar" = one post in lugnet.foo?), then the rating shown on the web page would be: lugnet.foo.bar 64 lugnet.bar.baz (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) No, I wouldn't be that cruel! :) :) (...) Absolutely, it can, yes. :) Any integer in the range 0 to 100 inclusive. The histogram display on the website snaps values to the nearest 10-stop. (...) Cool! --Todd (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) No, that's correct. Articles are, groups aren't. But a client could, if it wanted to, start messages off with any default number (not necessarily 50) based on which group(s) the article appears in. (...) The server does store the new composite (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) I think that's a typo... should be "lugnet.foo.bar:666 40 60 70 70 80" :) (...) well the way I see it (and Todd might prove me wrong) is that this way the client has the freedom to do whatever it wants with the ratings... such as have a (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) The downside, as I see it :) is that if the client just gets back one number per article somehow, it's an afternoon/evening hack to add this to a newsreader (like slrn) which already has GroupLens support. If the client has to actually process (...) (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) "Not as useful" doesn't mean "not exactly what Matthew wants". *grin* (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Oh! YES! Thank you. That exactly. (...) Yop! --Todd (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Well, maybe we can do both. Depends on the bandwidth and frequency of calls. --Todd (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Sorry, yah, I meant "not as maximally useful." --Todd (25 years ago, 6-Apr-00, to lugnet.admin.general)
|
| |
| | Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
|
(...) Well, I think it'd happen whenever slrn grabs headers for a newsgroup. That too much? (That would be in the case where there were a cgi which would take a list of articles [1] and return all values somehow. If it were a one request, one result (...) (25 years ago, 7-Apr-00, to lugnet.admin.general)
|
