It seems nearly nothing can be taken for granted ;).
It's best to just run against a big set of APIs and fix issues as they
arise though.
More flexibility means more maintenance, after all.
... it shows that the override I used previously won't work for `admin`.
Therefore we have to keep the actual value, instead of degenrating it.
Makes sense ... it's interesting how much one tends to hard-code things
to work just for a few cases, unless you opt in to see the whole picture
This file is completely generated, and allows us to easily bring in
new versions after each json update.
To make that work, we simple merge all data handed to mako-render,
inside of it. That way, we can put 'api/list' data in any yaml.
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
... .
However, this also means we need recursive builders, which is tottally
unsupported for now ... .
This means we have to generalize rbuild generation ... could be easy.
Lets see
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.
To avoid an additional type parameter, we will use dynamic dispatch
for the delegate.
Having function overrides at some point seems like an excercise better
left for version 1.1 ;)
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.
Was rather easy, and shows that plenty of complexity arose from the
usage example.
Implementing the action will probably be quite something ... .
Can't wait to have an auto-generated sample program !
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.
