Streaming support

[smortezah]

This format has the potential to transfer data beyond just serving as input for LLMs. A nice addition would be streaming data support. However, changes are needed like removing the size of arrays from the header. This will need to be optional even though it’s currently mandatory.

Are there any plans to implement this in the future?

[hermanndelcampo-theaiqueen]

Posting this feature for PR by Sunday I already created local tool on our solution.

[BrickDesignerNL]

@hermanndelcampo-theaiqueen how do we know the stream is at the end?
And if we stream wordt gRPC an alternative?

[hnfgns]

agreed. streaming would be a great addition to the spec. I came here to see if anyone raised this issue

Afaict the array declaration: key[length]{fields} can be lifted to a slice declaration like key[]{field1,field2,…} or skip brackets in entirety key{field1,field2,…}.

@hermanndelcampo-theaiqueen look forward to your spec.

[prb]

The forthcoming Jackson implementation jackson-future-ideas#96 (implementation already completed in (@prb/jackson-toon)[https://github.com/prb/jackson-toon/] supports streaming by design. The only unsupported features are path expansion and key folding (which are essentially impossible to support for the general case in streaming). (As a bonus here, if you had a Java webapp that was already using Jackson to stream out JSON, you could probably make near-trivial modifications to stream out TOON instead...)

The array serialization issue you point out was indeed a problem in writing the implementation, and unless the code doing the writing uses the Jackson facility to pass in a size hint, the whole array needs to be buffered before emission.

Allowingkey[]:{...} seems like a great optimization.