@qidi1 Do you think we can reuse the C SDK? Or can we extract common codes for both Go and C SDK

Thanks for raising this, @DorianZheng! I've been thinking about the architecture carefully.

Options Considered

Option A: Fully Reuse C SDK

Pros: Single source of truth, lower maintenance
Cons: C SDK becomes the "lowest common denominator" for all languages; changes require considering all consumers

Option B: Keep Separate (Current Implementation)

Pros: Full independence for each SDK
Cons: Duplicate FFI code, double maintenance cost, and Go's CGO goes through C ABI anyway — so the "independence" doesn't unlock much optimization

Option C: Extract a Shared FFI Core (boxlite-ffi-core)

Pros:

• Shared logic (error handling, JSON serialization, runtime management) lives in one place
• Each SDK can still extend with language-specific features if needed
• Clean architectural boundary: core handles "Rust → C ABI", each SDK handles "C ABI → language wrapper"
• Gradual evolution: if needs diverge later, we can add SDK-specific code without touching core

Cons:

• Requires a one-time refactor to extract the core
• Need to design the core API boundary carefully

My Preference

I lean toward Option C — extracting a boxlite-ffi-core crate.

Looking at the current code, most of it is shared logic (error handling, string helpers, JSON serialization). The extraction should be straightforward — it's mostly moving code around, no logic changes needed.

@qidi1 Good analysis. I agree with you. How about just boxlite-ffi

I think is good