Package com.tnsai.channels.api

Interface StreamingChannelAdapter

All Superinterfaces:
ChannelAdapter
All Known Implementing Classes:
CliChannel
public interface StreamingChannelAdapter extends ChannelAdapter
Optional mixin for ChannelAdapter implementations that can surface per-chunk deltas as an agent generates them (TNS-440).

Adapters that implement this interface signal — through ChannelCapabilities.streaming — that the framework should route per-token chunks via sendChunk(com.tnsai.channels.api.UnifiedChunk) as they arrive, instead of buffering and emitting one UnifiedResponse at the end. send(UnifiedResponse) still fires after the final chunk for adapter symmetry: it carries the full assembled reply for logging, audit, and downstream non-streaming consumers.

Adapters that DON'T implement this interface keep working as today — the gateway falls back to the buffered ChannelAdapter.send(com.tnsai.channels.api.UnifiedResponse) path. The mixin is purely additive; existing ChannelAdapter implementations need no change.

Implementations must be safe under concurrent invocation from multiple gateway threads (same contract as send).

Since:
0.10.2

  • Method Details

    • sendChunk

      void sendChunk(UnifiedChunk chunk)
      Deliver one UnifiedChunk to the channel. The adapter is expected to surface chunk.delta() immediately — flush the underlying transport so the user sees incremental progress.

      For text-only sinks (CLI stdout, plain HTTP SSE), this is usually a write + flush. For platforms with an editing model (Telegram, Slack) the recommended pattern is to send the first chunk as a new message and edit it on every subsequent non-empty chunk; flag done=true on the final chunk to release any "still typing…" affordance.

      Empty deltas (chunk.delta().isEmpty()) are valid — they may carry only metadata (e.g. a tool-call start marker). Adapters that only render text should treat empty deltas as no-op rather than throwing.