| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Third time must be where it sits I hope.
I felt the API was getting a bit too distracted by unnecessary
constructs and abstractions, so I'm trying to simplify it by making it
more straight forward.
The idea now is to have one main API class (ZotApi), and all the various
remote API's as public methods on this basic class. Iow, the ZotApi
class is mainly based on the existing `Client` class, which is then
being phased out.
And instead of having each API tied to the data type they return, I'm
just adding methods that will return the respective data types. This
should reduce coupling between the returned data, and the API calls
themselves.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The idea is to try to generate more of the boilerplate code, but for now
we only do the `z()` method definition. There are also some we're not
quite able to replace yet (like XChanRequest) since it also has life
times.
It's a start anyways :)
|
| |
|
|
|
| |
Doesn't seem like anything is changing re our code, but might as well
just stay with the lates.
|
| |
|
|
|
|
|
|
| |
This means adding the full tokio as a dependency. While there isn't much
gain to going async in the current cli demo app, a full fledged app may
have more to gain by it.
First foray into async rust, so I might not do it right...
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Simplifies serialization of various types quite a bit.
|
| | |
|
| | |
|
| |
|
|
|
| |
Provides matching against query params, so we don't need the ugly
regexes anymore.
|
| |
|
|
|
|
| |
For some reason the clap_app macro does not accept subcommands
with hyphens, so the subcommands `channel-strean` and `network-stream`
has been changed to `channel` and `network` respectively.
|
| | |
|
| | |
|
| |
|
|
| |
Only implements fetching the channel-stream for now.
|
| | |
|
| |
|
|
|
|
|
| |
Not entirely happy with it, have updated the signature of
Client::fetch_stream and Client::url to take args, which are left out if
they're not serializable (or empty, I hope.) Should probably use an
Option instead, or maybe even two entry points for the api.
|
| |
|
|
|
| |
This means we don't need to access internal data members of the Client
in builder structs an the like.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
