dartmouth-cs98 / 18w-si32 Goto Github PK

... because error handling is gonna suck w/ express

Users should have ability to sign up and sign in on the front-end.

Includes implementing a client-side session manager or something like that. The API returns a token from the registration and login endpoints which is the auth, to be used as a bearer token.

In working towards running tasks from the server, the worker should build/run a bot from a python file. For this task, just use a public .py hosted anywhere and implement the build process incorporating a downloaded file.

In terms of data modeling, I'm not sure how we want to store this. Maybe a game entry in the db stores some stats, and a url for the actual file log of the game?

What should the responses from the API look like? Do we want to include meta information?

As things stand...
I've started using an "updatedRecords" property on requests that create/modify records. On requests to fetch data, the response is (in most places) just the data itself.

User should be able to see a list of their existing bots

Endpoint exists at /bots

For API and web, enforce coding style w/ a pre-push hook

User should be able to select bots to compete in a match

Most of our front-end data will be pretty static. We should keep track of whether a request is needed instead of firing off requests every time a page is visited.

I think we can couple this with a "lastUpdatedDate" or something like that for the backend, so the backend only queries and returns things that have been modified since the front-end last pulled.

Right now we do

def write(self, line):
  self.proc.stdin.write(line.encode())

But this is not registered by the subprocess since we are not calling flush. This causes us to hang when we try to read from subprocess, since it is still waiting for input to its stdin.

When worker requests a next task and there are no queued matches, create and return a random (somewhat even?) match instead of just having the worker spin.

Just get some sample docs up for MVP.

What does the server expect players to be sending?

initial suggestion:

[
  {
     unitId: id,
     command: (number corresponding to command),
     direction: (if move was to move, what angle),
     square: (if move was to build, what square)
  }
]

After running make, still get

robinjayaswal 18w-si32/worker (python3) $ ./start.sh 
Unable to find image 'si32-child-bot:latest' locally
Unable to find image 'si32-child-bot:latest' locally
docker: Error response from daemon: pull access denied for si32-child-bot, repository does not exist or may require 'docker login'.
See 'docker run --help'.
b''
docker: Error response from daemon: pull access denied for si32-child-bot, repository does not exist or may require 'docker login'.
See 'docker run --help'.
b''

For now just manually built the child bot, Makefile skills are rusty and could not see from cursory glance why the child process was not getting run as part of make all.

cd child && docker build -t si32-child-bot .

If user uploads new bot version, remove any games for the old bot that have been queued but are not yet running

Workers need an endpoint they can hit to get a new task, that returns with all information needed to run a game.

For dev purposes at least, if there's no next requested task, just select two random bots and have them fight.

We should split out the game engine, and then just have the worker include the game as part of the docker build process

On logout, entire store should be cleared/reset

Subproblems:

• Docker container hitting Mac localhost

• Telling Docker what external url to hit

User should be able to see the matches they have created or are part of.

Endpoint exists at /matches

We need some koa middleware to catch/standardize error status codes and response bodies when there are errors.

As I see it, routes should throw new CorrectErrorType("what went wrong"), and the middleware set status codes/the body depending on what the error type was.

Implement ability to actually run the next task the server wants to happen. Hit the next task endpoint on the API, fetch, build, and run a game with user-provided code. Call the API endpoint to upload a game's results.

Depends on API endpoint for tasks and ability to download/run bot code.

to reflect page layout that will be saved somewhere in this repository.

We should all agree on exact definitions of what we are talking about (and exact classes/code we are referring to) when we say 'worker', 'game engine', 'bots' vs 'players', etc. These can be updated as our architecture changes, but as we go we should agree on working definitions.

Need API call to place new bot code over top old bot code and increase version number on a bot

User should be able to upload a new version of code, to an existing bot

Needs #38 and (probably) #36