TODO.txt

- user roles [IN PROGRESS]

- set up automatic CI (eg Travis)

- write another sample: implement a simple 'echo' service in scala using
  cfoundry-scala to advertise with CF etc.  this would be both a good
  sample, but also solid proof that the parts of the API related to
  services are well covered.
  
- CF sends resource properties in 2 sections: metadata and entity.  we
  don't really distinguish between them (properties have a 'metadata' flag,
  but it isn't very useful).  this gap is generally OK -- though it was
  a hassle to implement service's "url": there are two url properties,
  one in "metadata" as usual for all resources, and another in "entity".

- use www.scala-sbt.org

- tests should know whether they required admin or not (e.g. create
  service vs service instance); and mark themselves pending if they
  require admin but don't have it.

- all properties & relationships of all resources -- rather incomplete
  today.
  
- add a guid to every fake_foo_bar (see ResourceFixture#fakeFor), so
  subsequent tests to proceed if a prior test doesn't clean up
  its garbage (and enable parallel testing?!).  trivial, but let's
  wait until we're confident that fixture garbage collection is really
  working right. 

- Fake resources are generated in two different ways: CRUDTests#testCRUD
  and ResourceFixture#createResource.  Can/should these be unified?

- To avoid the endless race for cfoundry-scala to catch up to CF, can we
  eliminate all the code for each CF resource and it's
  properties/children/parents?  Two approaches:

   o Grab the entire payload from CC rather than plucking out known
    items; if CC sends "foo_guid" then infer parent Foo; if CC sends
    "foos_url" then infer child Foo; otherwise infer property "foo"
    (but we lose static typing -- so this is a bad idea).

  o Write a script to load CF cloud controller and use Ruby reflection
    to automatically generate the corresponding cfoundry-scala CF
    resource specifications.

- reimplement Java friendliness with the Scala macro feature when it
  supports adding new members to a class

- Scala consumption of the JF API is weak; for example the following
  does not compile: "for (org <- client.getOrganizations) { ... }".
  The following implicit conversation is inadequate: "implicit def
  resourceList2resourceBuffer[T <: Resource](list: java.util.List[T]):
  scala.collection.Iterable[T] = list"