Rob wrote: > At the moment, poltergeist supports storing the: > > * Match schedule > * Scores > * Team names
Also some other strings about teams, and it importantly calculates the league points from the game points (storing both). I agree these aren't really relevant to the point you're making though. > It stores these things in redis, and provides a notification over > redis's pubsub system when any of these things are updated. > > Does it really make sense to use redis for these things? It's a typed data store which we have wrappers for which we know work. While we may not be currently using the pub/sub, the fact that we have it and it works is pretty compelling. > However, it seems that none of the things that we'd really want to > subscribe to (for example, what match we are currently in, or how far we > are through it) are there any more. I'm not convinced by this. Even if we don't keep to schedule, the current delay state is something that _is_ stored in the system (albeit admittedly not in redis, because it was hacked in during last year's competition -- this was something I was going to fix). > So it seems to me that poltergeist is currently just a mechanism for > storing (pretty much) static data in redis. All of the above things > would be far simpler to store in some on-disk files. I'm not convinced that on-disk files are necessarily any easier than redis. I'll say again: we already have the relevant wrappers. > With the poltergeist, my understanding is that the scoring workflow > would be: > > 1. Enter match end-state into YAML file from form. > 2. Commit and push to scores git repo. > 3. (Somewhere else) Pull from that repo. > 4. (Somewhere else) Run a script that calculates the scores from > that match data and puts it into redis. > 5. Run a script that grabs that data from redis and outputs an HTML > file. > > Would it not be simpler to just: > > 1. Enter match end-state into YAML file from form. > 2. Commit and push to scores git repo. > 3. (Somewhere else) Pull from that repo. > 4. (Somewhere else) Run a script that calculates the scores and > outputs an HTML file. > > i.e. remove redis from the scenario, and make the match end-state git > repo the canonical source of data. Considerably simpler. Neither of these describes the scenario we had last year, and which I'd planned to replicate (and/or improve upon). That was: 0. Run wrapper script which generates a match yaml including the right TLAs. 1. Enter match end-state into YAML file from form. 2. _Optionally_ commit and push (primarily for backup purposes). 3. Run wrapper script #2 which scores the match. pipes the data to poltergeist, generates the new mardown/html and ships it at badger. Surely this is even simpler than needing to push/pull the scores around? Your scenarios both appear to involve several people who need to communicate that a scores update is available, though arguably this could be automated by running the pull/update as a cron job or similar. At the end of the day, redis or files on disk are just a data-store. This feels like the level of things I wanted to avoid having big discussions over rather than spending time implementing it. Especially since every previous attempt to re-write the competition software has ended up with someone/people (and for the past couple of years this has included me) fixing things last minute I'm vastly in favour of using the one we already have stuff which works for. Peter -- You received this message because you are subscribed to the Google Groups "Student Robotics Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
