aehmlo/lifxi

A Rust wrapper for LIFX bulbs.

lifxi's Issues

Use enums for client/request instead of traits

With the traits approach, we have a bunch of #[doc(hidden)] pub struct Foo going on, and we have a lot of duplication of methods that shouldn't really be necessary. If we can consolidate this into a large enum, we'll be able to get rid of a lot of this; however, this would mean that the library is no longer easily extensible. I'll have to put some thought into what to do here, but it's a "later" type of issue either way.

Combined selectors

Selectors can be concatenated with commas in between to make combined selectors (up to 25 selectors in length) in order to address multiple disparate devices at once. This isn't necessary for us to implement just yet, but I don't want to forget about it.

Request retrying

Introduce a method (retry? send_retry? send().retry()?) that automatically retries failed requests, waiting an appropriate duration if needed for rate-limiting.

Reduce client/request boilerplate

We currently have more boilerplate for each client/request pathway than we really need. Let's try to distill the information we need (path, method) into a couple of trait methods and move to using a more uniform type for the T in Request<'a, T>. We could even move to a trait method returning &impl Serialize or something, if that makes sense with the new structure.

Fast mode

Some endpoints support a "fast mode," so we should enable this in the client.

Enhanced response handling

I would like to handle the responses from the API a little further than the current "hand off the raw data to the consumer" approach manages. For instance, I'd like to be able to tell the user they're using an invalid token, or that their color is invalid. I'll probably do this by looking at the possible responses to each request as documented in the API docs and covering just those at first.

Serialization

Instead of continuing to build HashMaps and passing those to reqwest, we should leverage serde's awesome serialization capabilities. We should also deserialize API requests into nicely-typed objects, but that's another issue altogether.

Combining color components

We need to support creation and parsing of colors which contain multiple HSBK components (currently we support only one of these at a time). We shouldn't assume there's a guarantee on what order the components will be in, so we'll probably just split it up and match on each label (we'll probably want to use Option::swap and validate that we're not doing this more than once for each label).

Tidy up retry logic

We have lots of duplicated code around request retrying (#9) that I would like to remove. I don't see a way to store the information without adding some fields/methods to each struct in the chain, but maybe we can add a custom derive/procedural macro to make this less cumbersome.

LAN interface

We currently support the HTTP API, which is awesome, but let's also add support for the LAN version.

Add prelude for http module

All examples currently use use lifx::http::*, but there's stuff in there that people don't need (and possibly stuff that conflicts, like Duration), so let's add a prelude instead.