ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/CBOR-XS/XS.pm
(Generate patch)

Comparing CBOR-XS/XS.pm (file contents):
Revision 1.38 by root, Tue Dec 3 10:23:55 2013 UTC vs.
Revision 1.39 by root, Tue Dec 10 15:31:40 2013 UTC

330and you need to know where the first CBOR string ends amd the next one 330and you need to know where the first CBOR string ends amd the next one
331starts. 331starts.
332 332
333 CBOR::XS->new->decode_prefix ("......") 333 CBOR::XS->new->decode_prefix ("......")
334 => ("...", 3) 334 => ("...", 3)
335
336=back
337
338=head2 INCREMENTAL PARSING
339
340In some cases, there is the need for incremental parsing of JSON
341texts. While this module always has to keep both CBOR text and resulting
342Perl data structure in memory at one time, it does allow you to parse a
343CBOR stream incrementally, using a similar to using "decode_prefix" to see
344if a full CBOR object is available, but is much more efficient.
345
346It basically works by parsing as much of a CBOR string as possible - if
347the CBOR data is not complete yet, the pasrer will remember where it was,
348to be able to restart when more data has been accumulated. Once enough
349data is available to either decode a complete CBOR value or raise an
350error, a real decode will be attempted.
351
352A typical use case would be a network protocol that consists of sending
353and receiving CBOR-encoded messages. The solution that works with CBOR and
354about anything else is by prepending a length to every CBOR value, so the
355receiver knows how many octets to read. More compact (and slightly slower)
356would be to just send CBOR values back-to-back, as C<CBOR::XS> knows where
357a CBOR value ends, and doesn't need an explicit length.
358
359The following methods help with this:
360
361=over 4
362
363=item @decoded = $cbor->incr_parse ($buffer)
364
365This method attempts to decode exactly one CBOR value from the beginning
366of the given C<$buffer>. The value is removed from the C<$buffer> on
367success. When C<$buffer> doesn't contain a complete value yet, it returns
368nothing. Finally, when the C<$buffer> doesn't start with something
369that could ever be a valid CBOR value, it raises an exception, just as
370C<decode> would. In the latter case the decoder state is undefined and
371must be reset before being able to parse further.
372
373This method modifies the C<$buffer> in place. When no CBOR value can be
374decoded, the decoder stores the current string offset. On the next call,
375continues decoding at the place where it stopped before. For this to make
376sense, the C<$buffer> must begin with the same octets as on previous
377unsuccessful calls.
378
379You can call this method in scalar context, in which case it either
380returns a decoded value or C<undef>. This makes it impossible to
381distinguish between CBOR null values (which decode to C<undef>) and an
382unsuccessful decode, which is often acceptable.
383
384=item @decoded = $cbor->incr_parse_multiple ($buffer)
385
386Same as C<incr_parse>, but attempts to decode as many CBOR values as
387possible in one go, instead of at most one. Calls to C<incr_parse> and
388C<incr_parse_multiple> can be interleaved.
389
390=item $cbor->incr_reset
391
392Resets the incremental decoder. This throws away any saved state, so that
393subsequent calls to C<incr_parse> or C<incr_parse_multiple> start to parse
394a new CBOR value from the beginning of the C<$buffer> again.
395
396This method can be caled at any time, but it I<must> be called if you want
397to change your C<$buffer> or there was a decoding error and you want to
398reuse the C<$cbor> object for future incremental parsings.
335 399
336=back 400=back
337 401
338 402
339=head1 MAPPING 403=head1 MAPPING

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines