* macro 'alias' was renamed to 'rename'
* fixed `cargo test` on main project
The latter pointed me to the serde issue, which would have made
everything fail when actually used to communicate with google servers.
This allows us to build efficiently. CLI programs can now have their
own cmn.rs implementation, which we can test standalone with
`cargo test`.
The primary makefile currently just explicitly pulls in the type-*.yaml,
one day we could possibly put it into a loop.
Fixes#11
Previously, it would query the size from the wrong dict and obtain
the value 0 all the time. This would have made every upload fail with
`UploadSizeLimitExeeded`.
Now we obtain the actual size limit, and will ignore it if unset/0
for some reason.
Patch += 1
That way, crate names reveal exact inforamtion about the contained
API revision.
* crate version: code gen version
* +<revision> (build-metadata): exact version of API schema
Fixes#38
* renamed `*MethodsBuilder` type to `*Methods` type
* renamed `*CallBuilder` type to `*Call` type
* greatly simplified `doit()` signature if uploads are involved
* pass `auth` to upload helper
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
With one of the recent changes, the crate name was changed to be
different from the library name. However, there were still plenty of
places that would refer to the library name instead of the new crate
name.
That way, links in the README.md as well as index/index.html still
pointed to the old location.
* 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
Now I just add a 'virtual' resource, which is called 'methods'.
The good thing about this is that it works well standalone, or
in conjunction with actual resources.
Also the system works with it just with minimal changes
Fixes#19
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
... .
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 ... .
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.
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.
Now comes the actual work of setting them up.
Additionally, the docs were decluttered to show comments only
were necessary. Now the code path to getting the hub is as concise as
possible.
Makes everything evaluate faster, and is good enough as well.
Besides, you don't have to think about whitespace too much, keeping
things simpler is usually better
This works with a new `indent` and `unindent` filters respectively.
There are a few things to consider, but I have understood how it works
and can handle it.
There is some overhead just to give me nicer visuals ... might choose
a different route, like annotations.
This includes docs for the library usage.
It's totally great to be able to paste example code right were it
belongs, and also put the same elsewhere to compose more complex docs.
Everything we have, feature wise, is now documented in a first version
at least.
We shall keep this uptodate with what we are implementing, which also
helps figuring out a good api.
A note like that is now added to all files we generated, commented out
depending on the file type.
Quite neat, except that for filtering, I always have to use blocks.
Now a context is passed to utility functions, which contains the state
these may be interested in. This keeps it clean from global state.
With the lookup tables, it is possible to figure out relations between
types and document them accordingly.
