search

Mri-monitoring / Mri-python-client

Python client for Mri server, supports easy plotting/updating
Apache License 2.0
4 stars 1 forks source link

Re-architect to allow access to server directly #1

Closed nharada1 closed 9 years ago

nharada1 commented 9 years ago

Right now each dispatch represents a single task. This is good, except that there isn't a logical place to put functions that perform whole-server tasks. As the server itself becomes more important, we need to start thinking about making a full server object instead of just dispatches.

The issue is I don't want to remove the Matplotlib dispatch just yet. Maybe we make a Server object that then can create new tasks on the server? I think the server is the future and eventually Matplotlib will be useless, but then how stateful do we make the Server object?

Options:

  1. The Server object is straight up linked to the Mri-server instance. We retain state and update based on the reports and visualizations on the server. This is great for the user, but presents problems. What if we want to run multiple instances of training at once? How do we retain state across sessions that are, by definition, stateless?
  2. The Server object contains a lighter wrapper to the server API. We can basically do things to the server, but we are stateless. We could retain a list or queue of MriServerDispatch's for training. Eventually this would probably lead to the death of the Matplotlib dispatcher, and make the idea of the dispatch kind of useless since the only dispatch is to the server. Still, this is probably the Right Thing to Do.
nharada1 commented 9 years ago

This should be done before the release to avoid ruining the API in the future. An API doc should be written first and then implemented.