To-do list

Syntax changes

Embed connection in object pointers (planned for v0.5.0)

This will allow you to do things like

vessel = SpaceEx.SpaceCenter.active_vessel(conn)
orbit = SpaceEx.SpaceCenter.Vessel.orbit(vessel)
apoapsis = SpaceEx.SpaceCenter.Orbit.apoapsis_altitude(orbit)

Note the lack of conn in lines 2 and 3. The idea here is that — although you could always specify conn if you really want — by default, it’ll use the same connection you used to retrieve the object. This also allows the above code to be simplified down to

apoapsis =
  SpaceEx.SpaceCenter.active_vessel(conn)
  |> SpaceEx.SpaceCenter.Vessel.orbit
  |> SpaceEx.SpaceCenter.Orbit.apoapsis_altitude

To use an object via a different connection, there will be a Connection function; I’m currently thinking Connection.reassign(obj), although rehome and claim are other possibilities.

Keyword-based function arguments w/ default values (planned for v0.5.0)

Functions with optional arguments will have said arguments condensed into an opts keyword list.

# Old syntax:
defmodule SpaceEx.SpaceCenter do
  def warp_to(conn, ut, maxRailsRate, maxPhysicsRate)
end

# New syntax:
defmodule SpaceEx.SpaceCenter do
  def warp_to(conn, ut, opts \\ [])
  # with optional opts[:max_rails_rate], opts[:max_physics_rate]
end

Note that I don’t currently have any plans to make extra variants where all parameters are specified via keywords.

Cleanups

Hide/rename core I/O functions

Certain functions like KRPC.add_stream should probably be marked as @doc false (or otherwise flagged as “don’t use this”), because their behaviour is provided by core classes.

Of course, we can’t just get rid of those functions, because they’re actually used by the functionality in question. But we can potentially rename them.

Tests

Considering the API is automatically generated based on JSON definitions, the protocol is raw binary over TCP, and the server requires a running instance of a graphically intensive game with manual input required to set it up, I don’t think SpaceEx will ever have full end-to-end integration tests, or particularly high test coverage across the entire API.

However, that certainly doesn’t mean that tests are impossible. It should be pretty easy to come up with a mock test object that expects certain requests and generates canned replies. Maybe these could be recorded from live traffic, similar to ExVCR and similar “remote but not remote” test utilities.

Plus, simply testing that key functions exist, have the expected arity, and accept the expected object types would go a long way towards improving confidence while hacking on the library, particularly the SpaceEx.Gen macro code.

An early obvious candidate for testing are the type encoders and decoders. These can be easily tested using both encoding/decoding between known values and binary strings, and encoding/decoding random values, with no remote server or mocking.

Current test protocol is to run all the scripts in examples. This has moderately decent coverage, but is far from complete.