Difference between revisions of "Talk:Darkcanuck/RRServer/Query"

From Robowiki
Jump to navigation Jump to search
(Compression and encoding)
m (→‎Desired queries: remove signature that got thrown in a stupid place)
Line 5: Line 5:
 
* PARAMS: Bot/Version, Rumble; RETURN: APS
 
* PARAMS: Bot/Version, Rumble; RETURN: APS
 
* PARAMS: Bot/Version, Rumble; RETURN: Ranking (eg, 9th)
 
* PARAMS: Bot/Version, Rumble; RETURN: Ranking (eg, 9th)
--[[User:Rednaxela|Rednaxela]] 20:57, 6 August 2009 (UTC)
 
 
These might be nice, so I'll post them for sake of brainstorming, but they're not needed by me:
 
These might be nice, so I'll post them for sake of brainstorming, but they're not needed by me:
 
* PARAMS: Bot/Version, Rumble; RETURN: Glicko-2
 
* PARAMS: Bot/Version, Rumble; RETURN: Glicko-2

Revision as of 22:12, 6 August 2009

Desired queries

I'm currently interested in queries to enable tweets about RoboRumble entrants once they've achieved a stable rating. For that, I think I'd need the following:

  • PARAMS: Bot/Version, Rumble; RETURN: Battle count
  • PARAMS: Bot/Version, Rumble; RETURN: APS
  • PARAMS: Bot/Version, Rumble; RETURN: Ranking (eg, 9th)

These might be nice, so I'll post them for sake of brainstorming, but they're not needed by me:

  • PARAMS: Bot/Version, Rumble; RETURN: Glicko-2
  • PARAMS: Bot/Version, 1v1 or Melee; RETURN: Lowest weight class
    • Can be deduced from querying with each of the 4 rumbles, anyway.
  • PARAMS: Bot/Version, Rumble; RETURN: Pairings complete? (boolean)
    • Can be assumed complete for battle count > 2000.

--Voidious 14:37, 6 August 2009 (UTC)

The one I'd mostly be interested in would be the following:

  • PARAMS: Rumble, Timestamp(optional); RETURN: All paring details (bot names, score, survival, maybe battle count) in Rumble (that had a battle since Timestamp).

It would make it easy to get/update test data for doing analysis of how bots do against other bots.

--Rednaxela 15:43, 6 August 2009 (UTC)


I'm thinking, some of this stuff could be quite a bit of data. Perhaps it would be better to put it all into a zip file before returning it? --Skilgannon 19:48, 6 August 2009 (UTC)

Err... zip file? A raw deflate or gzip stream would be less overhead and much saner. Zip files are for archiving groups of files, not compress raw data. Actually, if the web server is set up correctly, it can transparently compress anything coming out of it as it sends to the client, so long as the client said in the http header that it accepts compressed responses (which as a note, firefox for one does on any web page). Anyway, might I suggest that maybe the query results should be encoded in JSON, since this is a very simple low-overhead format, which php has a builtin function to serialize to? --Rednaxela 20:57, 6 August 2009 (UTC)