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.
18#![allow(dead_code)]
19#![recursion_limit = "512"]
20
21mod config;
22mod download;
23mod error;
24mod http;
25mod js;
26mod plan;
27mod state;
28mod tune;
29mod upload;
30
31pub use config::{backoff_ms, ClientConfig};
32pub use error::LibfwError;
33pub use plan::FileEntry;
34pub use tune::{
35 CompressLevel, TuneEvent, TuneHandle, TuneParams, TunePhase, TuneStats, TransferKind,
36};
37// Re-exported so consumers can name the capability/limit types returned by
38// `native::NativeClient::{capabilities, fetch_capabilities}` without having to
39// depend on `libfw-core` directly.
40pub use libfw_core::{Capabilities, CompressionFormat, IntRange, Limits, ZripLevels};
41
42/// Native (non-WASM) Rust client: async `reqwest` transport speaking the same
43/// wire protocol as the browser engine.
44#[cfg(not(target_arch = "wasm32"))]
45pub mod native;
46
47#[cfg(target_arch = "wasm32")]
48pub mod wasm;
49#[cfg(target_arch = "wasm32")]
50pub use wasm::{js_option_string, LibfwClient};