nv-redfish-core 0.1.2

Semantic-unaware foundation used by code generated from CSDL for nv-redfish
Documentation
# nv-redfish

A modular Redfish client stack for Rust.

## Repository structure

- core: Semantic-unaware foundation used by code generated from CSDL
  - Primitives and traits: `Bmc`, `EntityTypeRef`, `Expandable`, `NavProperty<T>`, `Action<T,R>`, `ODataId`, `ODataETag`, `EdmDateTimeOffset`, `EdmDuration`, `Empty`
  - Optional HTTP client behind the `reqwest` feature (enabled by default) in `core::http` (`ReqwestClient`, `HttpBmc`)
  - Goal: provide the minimum building blocks for generated code; no service-specific logic

- redfish: High-level ergonomic wrappers over generated Redfish schema types
  - Feature-gated services (enable only what you need): e.g., `accounts` (implemented), `events` (planned)
  - OEM extensions planned, also under features
  - Patch support (`redfish::patch_support`) to handle vendor quirks while maintaining compatibility
  - Uses generated types included via `redfish::schema` (autogenerated by the CSDL compiler)

- csdl-compiler: CSDL (OData) schema compiler and Rust code generator
  - Reads Redfish (and OEM) CSDL XML, compiles a subset, and generates Rust code
  - Two primary compilation modes:
    - Compile: compile a subset rooted at specific singletons (e.g., `Service`)
    - CompileOem: compile OEM schemas and include them in the root set
  - Entity type inclusion can be controlled with wildcard patterns; only needed types are compiled
  - The generator produces Rust modules and types consumed by the `redfish` crate
  - CLI: `csdl-compiler` with subcommands in `csdl-compiler/src/commands.rs`

## How the pieces fit together

1. Choose features in `redfish` (services, OEM flags). The selected features determine which schemas to include (see `features.toml`) and which high-level wrappers are built.
2. The build uses `csdl-compiler` to generate only the required schema types into the `redfish` crate (via `build.rs`), keeping the binary lightweight.
3. The high-level `redfish` APIs (e.g., `ServiceRoot`, `accounts`) operate over the generated types and the `core` primitives.
4. Provide a `Bmc` implementation. With `core`’s `reqwest` feature, use `HttpBmc<ReqwestClient>`; otherwise, plug in your own transport.

## Feature flags

- core:
  - `reqwest` (default): enables the HTTP client implementation
- redfish:
  - `accounts`: AccountService wrappers (implemented)
  - `events`: Events service wrappers (planned)
  - OEM extensions: planned per vendor, also feature-gated

## Example

Minimal shape (pseudocode):

```rust
use nv_redfish_core::http::{HttpBmc, ReqwestClient};
use nv_redfish_core::bmc::BmcCredentials;
use nv_redfish_redfish::ServiceRoot;
use std::sync::Arc;
use url::Url;

# async fn run() -> Result<(), Box<dyn std::error::Error>> {
let bmc = Arc::new(HttpBmc::new(
    ReqwestClient::new()?,
    Url::parse("https://192.168.1.100")?,
    BmcCredentials::new("admin".into(), "password".into()),
));

let root = ServiceRoot::new(Arc::clone(&bmc)).await?;

// If `accounts` feature is enabled:
// let accounts = root.account_service().await?;
// let collection = accounts.accounts().await?;
// println!("{}", collection.odata_id());
# Ok(())
# }
```

## Goals

- Be as lightweight as possible:
  - Compile only schemas referenced by enabled features (`features.toml` driven).
  - Keep the core minimal and transport-agnostic.
- Support a variety of vendors compatibly:
  - Feature-gated OEM extensions.
  - Patch support for schema deviations in real-world BMCs.

## License

See workspace `Cargo.toml`.

This project includes Redfish schema files from DMTF’s [Redfish-Publications repository](https://github.com/DMTF/Redfish-Publications/tree/main), licensed under the [BSD-3-Clause license](redfish/schemas/redfish-csdl/LICENSE).

This project includes Swordfish schema files from [SNIA](https://www.snia.org/forums/smi/swordfish), licensed under the [BSD-3-Clause license](redfish/schemas/swordfish-csdl/LICENSE) 

## Contributing

Please see [CONTRIBUTING.md](CONTRIBUTING.md) for details.