Now json errors are handled and delegated with the option to retry,
and all other values are just decoded according to plan.
For now, I brutally unwrap json values assuming this will work, because
it really should work.
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.
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.
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 :) !!
That way, we don't have recursive method builders, but instead
flatten the hierarchy. In our case, this is easier and means
less to type. E.g.
`hub.user().message().import(...)` now is
`hub.user().message_import(...)`
In go it would look like this though
`hub.user.messages.import(...)
which is neater.
We will never have that though, as it will initialize a massive amount
of data right on the stack, even though only some of it is ever used
... .
That way, we make retrieved tokens independent of the order scopes
were passed in. Additionally, we can pass any scopes, just in case
someone uses one token for multiple APIs.
Let's keep it flexible.
... however, it will become an enumeration, as I don't like people
putting in strings all by themselves. This also means we have to
generate good enums ourselves.
It works for uploads as well as for others.
Next up is to setup the head and authentication. It will be as simple
as calling and handling `GetToken`, even though I think that there
needs to be better support for the scope that is asked for ... .
Now query params are handled completely, including clash check.
Additionally, there is a new result type which encapsulates everything.
It must be typed to the actual result type though, which can be a
request result
Custom property annotations have been very useful, to steer very special
cases.
It's also good that now there is enough infrastructure to deal with
any amount of additional type parameters.
With a big but ! The most simple thing to do it was to just add
additional type parameters to the respective method.
Now the type cannot be inferred, which means type-hints must be added.
This should be easy enough, but ... has to be done somehow.
Just to have another, different set of api information to deal with,
and not accidentally hard-code things to work with youtube only.
Prepared dealing with media uploads, and it turns out to be best to
adjust the 'doit()' to take the respective type parameter.
We also have to think about downloads, like the ones for google drive,
which requires custom query parameters.
This might mean we need additional type parameters, but I will see how
it's going to work out.
In theory, we could define a new trait for Seek+Read, but this would
mean that we couldn't contain owned streams.
For max flexibility, it's better to have additional type parameters
and use BorrowMut to allow ownership, and borrow.
Previously, it would just show all parts.
It's still not correct though as this isn't necessarily the parts used
in the request value, but only the ones in the response value.
It's as good as it gets though, that's all the information contained
in the json.
It's not as good as the parts info on the website, but it's something !
At least people don't have to read the text, but find this information
in all the spots that are relevant to this.
With nearly fully randomized examples to show how it can be done.
It's quite nice to see actual calls, using everything required to get
a call. The only thing the user has to manage is to fill in actual
values.
But, it also shows that our builder pattern doesn't work yet due to ...
you guessed it ... lifetime issues :D
What's missing is docs, which will see some work now.
I guess it will be best to hide all the prelude from the user, to allow
him to focus on what's important here.
Now we will generate proper resoure methods builder calls to instaniate
the more or less valid method builders.
However, it doesn't compile yet, and the 'to_parts()' method on
resources is still missing.
Previously, they would take everything as reference and clone
everything unconditionally. Now we do it only as we need to do it,
no extra work incurred.
This includes descriptions, of course, and generally seems to look
quite neat. For now, we brutally consume all input to own it,
but in future we might be able to put in Borrow to support them all.
