libfw_client/lib.rs
1//! libfw-client: reusable client-side transfer logic and browser glue.
2//!
3//! The crate is intentionally split into a reusable Rust library core and a
4//! thin `wasm` bridge. This allows the client logic to be consumed by Rust
5//! code directly, while the JS/browser-facing API remains in the dedicated
6//! WASM module.
7//!
8//! # Two client forms, one protocol
9//!
10//! * **Native Rust** ([`native::NativeClient`], any non-`wasm32` target):
11//! an async `tokio` + `reqwest` transport implementing the same wire
12//! protocol — resumable `Range` downloads, the session upload protocol,
13//! zrip compression and the same adaptive tuning engine. Enable it by
14//! depending on this crate from a normal Rust binary/library.
15//! * **Browser/WASM** (`LibfwClient`, `wasm32` only): the engine behind the
16//! `sdk/` npm package, which additionally supports the File System Access
17//! API and IndexedDB resume state. Its JavaScript API is documented in
18//! `sdk/README.md` and `sdk/index.d.ts`.
19#![allow(dead_code)]
20#![recursion_limit = "512"]
21
22mod config;
23mod download;
24mod error;
25mod http;
26mod js;
27mod plan;
28mod state;
29mod tune;
30mod upload;
31
32pub use config::{backoff_ms, ClientConfig};
33pub use error::LibfwError;
34pub use plan::FileEntry;
35pub use tune::{
36 CompressLevel, TuneEvent, TuneHandle, TuneParams, TunePhase, TuneStats, TransferKind,
37};
38// Re-exported so consumers can name the capability/limit types returned by
39// `native::NativeClient::{capabilities, fetch_capabilities}` without having to
40// depend on `libfw-core` directly.
41pub use libfw_core::{Capabilities, CompressionFormat, IntRange, Limits, ZripLevels};
42
43/// Native (non-WASM) Rust client: async `reqwest` transport speaking the same
44/// wire protocol as the browser engine.
45#[cfg(not(target_arch = "wasm32"))]
46pub mod native;
47
48#[cfg(target_arch = "wasm32")]
49pub mod wasm;
50#[cfg(target_arch = "wasm32")]
51pub use wasm::{js_option_string, LibfwClient};