However, for some reason, the `Serialize/Deserialize` macros don't work
for me, even though they work just fine in the respective tests of
the serge crate. What am I possibly doing wrong ?
Now we use the DefaultDelegate as standin in case there is user-delgate.
That way, we save plenty of complexity as no additional
`if let Some(ref mut dlg) = delegate` is necesary.
Fixes#30
During `begin()`, the delegate receives additional information about the
current call, which can be useful for performance tracking, among
other things.
Fixes#25
We assure to know about it, instead of writing nonsense about that
'methods' resources which does not actually exist.
I am relatively sure to have found all the spots.
Fixes#22
* add method listing for various categories, like 'downloads' and
'uploads'
* add general information on how to do downloads and uploads using
various protocols
Fixes#28
This also includes documentation to state which methods actually support
media download, and how to achieve that.
Added TODO to not forget we should tell the user how to achieve these
kinds of things.
Fixes#21
* MultiPartReader is using match to handle state, reducing unnecessary
calls to 0 in that regard.
* Fixed seek() calls on readers, assuring they are reset to start each
time the loop is done.
* both media-parameters now use `ReadSeek` streams.
* Use `seek()` to figure out size, simplifying the interface.
Closes#17
* reserve_exact(X) where possible (params, multi-part-reader)
* `if let` used whereever possible to prevent duplicate checks
This increases the possible performance, and makes for more readable,
concise code.
Those were totally real, actually, and I am happy the borrow checker
exists !
Only one weirdness happened with RefCell<BorrowMut<C>>, but it could be
fixed by checking actual types using `let foo: () = something_nasty()`.
* outer frame of `MultiPartReader` to allow using it in `doit()`
* restructured `doit()` to get content-types right
There is more work to do, as it currently doesn't compile, nor
do we deal with our streams correctly.
But we are on a good way.
URL expressions allow to substitute values within the URL with
parameters. However, this is not only a simple key-value replacement,
but supports expressions that need a parser.
This one will have to be implemented next.
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.
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.
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 :) !!
This involves disabling the dead-code lint, which is just to ease
debugging, currently there is a lot of dead code as 'hub' is never used.
Soon, this will change, so the lint will be enabled again.
... 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
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.
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 ... .
