search

OpenLEADR / openleadr-rs

OpenADR 3.0 VTN and VEN implementation in Rust
Other
9 stars 4 forks source link

Write a meaningful CLI using the client library #52

Open pohlm01 opened 2 weeks ago

pohlm01 commented 2 weeks ago

The intention is to create a CLI application that uses the openleadr-client crate to allow users to create/update/modify/delete programs/events/reports/vens/resources on the VTN.

The file openleadr-client/src/bin/cli.rs contains a stub for a CLI application, which needs to be filled.

KeeganMyers commented 2 weeks ago

I can pick this up. I will probably use clap crate unless you have strong feelings otherwise.

pohlm01 commented 2 weeks ago

Sounds good to me

KeeganMyers commented 1 week ago

https://github.com/OpenLEADR/openleadr-rs/pull/60 covers this issue

KeeganMyers commented 2 days ago

Based on your comments in the closed PR I'm looking through types like VenClient the need to pass self is an issue for CLI interaction since constructing that type requires a Ven . What would more closely match your design pattern, remove &self and replace it with applicable params to identify the ven, or create a new type similar to VenClient for Cli interop?

KeeganMyers commented 2 days ago

For reference sake I'm using clap with derive sub commands to mimic the structure of k8s or docker commands i.e

./cli ven ls
./cli ven get id=11232

If we removed self from VenClient we could then call mutations with

./cli ven delete id=123

But at the moment the need to first create the struct makes that more difficult rather than just passing id directly to VenClient::delete

pohlm01 commented 2 days ago

Hm, that's a good one. We did not really consider that when designing the API of the client library.

Maybe there is a third option we could consider. If you want to delete a Event you first GET it and then DELETE it. This would effectively be one unnecessary request, but I don't think it harms a lot. For most other modifying interactions besides DELETE, this pattern also seems helpful, if not necessary, to me. For example, when modifying an Event you probably want to set individual fields in the CLI, while the PUT request requires all fields to be present. Therefore, you would need to send a GET request before anyway.

./cli event update id=123 priority=5 # no need to provide all other event fields

Another example would be if you want to create a Report underneath an Event. According to the spec, you have to provide the ProgramID and EventID (which is a bit wired if you ask me). Instead of requiring the ProgramID as CLI argument, we would GET the Event and use the ProgramID stored in there.

What do you think of this approach?