New Client API

[robertmaynard]

Lets change around the client api so that all the method calls follow a more consistent
naming convention.

class Client
{
  //return the connection info that was used to connect to the
  //remus server
  const remus::client::ServerConnection& connection() const;

  //Submit a request to the server to see if the server supports
  //the requested input and output mesh types
  bool canMesh(const remus::common::MeshIOType& meshtypes);

  //Submit a request to the server to see if the server supports
  //the exact requested requirements
  bool canMesh(const remus::proto::JobRequirements& requirements);

  //submit a request to the server to see if the server supports
  //the request input and output mesh types. If the server does support
  //the given types, return a collection of JobRequirements
  remus::proto::JobRequirementsSet requirements( const remus::common::MeshIOType& meshtypes );

  //Submit a job to the server. The job submission has a JobData and
  //a JobRequirements component
  remus::proto::Job submit(const remus::proto::JobSubmission& submission);

  //Given a remus Job object returns the status of the job
  remus::proto::JobStatus status(const remus::proto::Job& job);

  //Return job result of of a give job
  remus::proto::JobResult results(const remus::proto::Job& job);

  //attempts to terminate a given job, will kill the job if the job hasn't
  //started. If the job has been finished and the results
  //are on the server the results will be deleted. If the job is in process
  //this will be unable to kill the job.
  remus::proto::JobStatus terminate(const remus::proto::Job& job);

};

[robertmaynard]

With the addition of querying the server for all MeshIOTypes and possibly the addition of sessions to Remus, this should be done after those tasks are completed.

Blocked by issues #123 and #124

[robertmaynard]

I believe that with the advent of clients being able to retrieve the supported MeshIO types from a server I believe a better interface would be:

class Client
{
  //return the connection info that was used to connect to the
  //remus server
  const remus::client::ServerConnection& connection() const;

  //Submit a request to the server to see what MeshIOTypes are supported   
  remus::common::MeshIOTypeSet supportedIOTypes();

  //Submit a request to the server to see if the server supports
  //the exact requested requirements
  bool canMesh(const remus::proto::JobRequirements& requirements);

  //submit a request to the server to see if the server supports
  //the request input and output mesh types. If the server does support
  //the given types, return a collection of JobRequirements
  remus::proto::JobRequirementsSet requirements( const remus::common::MeshIOType& meshtypes );

  //Submit a job to the server. The job submission has a JobData and
  //a JobRequirements component
  remus::proto::Job submit(const remus::proto::JobSubmission& submission);

  //Given a remus Job object returns the status of the job
  remus::proto::JobStatus status(const remus::proto::Job& job);

  //Return job result of of a give job
  remus::proto::JobResult results(const remus::proto::Job& job);

  //attempts to terminate a given job, will kill the job if the job hasn't
  //started. If the job has been finished and the results
  //are on the server the results will be deleted. If the job is in process
  //this will be unable to kill the job.
  remus::proto::JobStatus terminate(const remus::proto::Job& job);
};

The notable change is the removal of canMesh that accepts just MeshIOType, as that
has become unneeded, as you can now query the server for all supported MeshIOTypes.

[vibraphone]

I would change the name of "canMesh" to something less specific to meshing, such as "acceptsRequirements".