This doesn't work yet, as I am unable to unwrap the client properly.
It's a refcell that contains a BorrowMut to a hyper::Client, and
lets just, it's complicated.
This caused cargo on a case-sensitive file-system not to find the
cargo file, which made it to look upwards in the directory structure
to find the correctly named Cargo.toml fo the 'cmn' development
project.
Previously, travis would continuously overwrite my combined docs with
the ones from the dev-project, and make them useless.
This has been driving me nuts ! Good to have it fixed !
Previously, I would just assign all useful traits to all types, no
matter on how they were actually used.
Now it builds all dependnecies and considers them when assigning
traits, which is as precise as we need it.
This is important to us as the `Json` type is just encodable, but
not decodable. Fortunately, we just have to encode it, but in theory
this makes it hard to embed any json in a known structure.
Due to shared global state which was altered, we got wrong results.
This is fixed now, thanks to a deepcopy. Amazing, how altering global
state is always biting you, even though you are convinced it's safe
to do in just this case !
General rule: Just don't do it, no matter what !
Into a complete, global list of schemas, with additional meta-data.
However, it's currently not complete, as $refs are missing.
There is some resemblance to to_rust_type(...), which worries me
slightly
It is a Json object, with a schema as defined elsewhere. It's quite
cool to see this (nearly) working already. However, it will require
us to transitively assign the required markers which is based
on information we don't currently have.
Maybe implementing this could also help to simplify name-clash checks
or make them better at least ?
It was possible for a nested type to be generated with a name that in
fact CLASHED with an existing schema type. What are the odds !
The clash-check added will just verify against clashes with schema
types, which seems to be doing it for now.
At least so it appears.
The implementation doesn't look totally clean to me, as it seems
similar concerns are in different portions of the code, which was
merely tuned to work together.
It could break appart if someone - me - wants to change it sometime
These are arrays or HashMaps, which are nested types too. This is used
to have custom types of standard vectors or hashmaps, which resolve
to NewTypes in Rust.
It seems we do it better than the actual Go implementation, which fails
to detect that scopes are actually having a string member.
However, there still is an issue, as it's as hashmap for us, but just
a member for go ... lets see ...
https://developers.google.com/discovery/v1/reference/apis#resource
shows that we implement it correctly :) !!
