--- CBOR-XS/XS.pm	2013/12/02 06:39:03	1.37
+++ CBOR-XS/XS.pm	2016/02/08 04:26:01	1.47
@@ -66,7 +66,7 @@
 
 use common::sense;
 
-our $VERSION = 1.11;
+our $VERSION = 1.4;
 our @ISA = qw(Exporter);
 
 our @EXPORT = qw(encode_cbor decode_cbor);
@@ -220,8 +220,13 @@
 If C<$enable> is false (the default), then C<decode> will throw an error
 when it encounters a self-referential/cyclic data structure.
 
+FUTURE DIRECTION: the motivation behind this option is to avoid I<real>
+cycles - future versions of this module might chose to decode cyclic data
+structures using weak references when this option is off, instead of
+throwing an error.
+
 This option does not affect C<encode> in any way - shared values and
-references will always be decoded properly if present.
+references will always be encoded properly if present.
 
 =item $cbor = $cbor->pack_strings ([$enable])
 
@@ -335,6 +340,70 @@
 
 =back
 
+=head2 INCREMENTAL PARSING
+
+In some cases, there is the need for incremental parsing of JSON
+texts. While this module always has to keep both CBOR text and resulting
+Perl data structure in memory at one time, it does allow you to parse a
+CBOR stream incrementally, using a similar to using "decode_prefix" to see
+if a full CBOR object is available, but is much more efficient.
+
+It basically works by parsing as much of a CBOR string as possible - if
+the CBOR data is not complete yet, the pasrer will remember where it was,
+to be able to restart when more data has been accumulated. Once enough
+data is available to either decode a complete CBOR value or raise an
+error, a real decode will be attempted.
+
+A typical use case would be a network protocol that consists of sending
+and receiving CBOR-encoded messages. The solution that works with CBOR and
+about anything else is by prepending a length to every CBOR value, so the
+receiver knows how many octets to read. More compact (and slightly slower)
+would be to just send CBOR values back-to-back, as C<CBOR::XS> knows where
+a CBOR value ends, and doesn't need an explicit length.
+
+The following methods help with this:
+
+=over 4
+
+=item @decoded = $cbor->incr_parse ($buffer)
+
+This method attempts to decode exactly one CBOR value from the beginning
+of the given C<$buffer>. The value is removed from the C<$buffer> on
+success. When C<$buffer> doesn't contain a complete value yet, it returns
+nothing. Finally, when the C<$buffer> doesn't start with something
+that could ever be a valid CBOR value, it raises an exception, just as
+C<decode> would. In the latter case the decoder state is undefined and
+must be reset before being able to parse further.
+
+This method modifies the C<$buffer> in place. When no CBOR value can be
+decoded, the decoder stores the current string offset. On the next call,
+continues decoding at the place where it stopped before. For this to make
+sense, the C<$buffer> must begin with the same octets as on previous
+unsuccessful calls.
+
+You can call this method in scalar context, in which case it either
+returns a decoded value or C<undef>. This makes it impossible to
+distinguish between CBOR null values (which decode to C<undef>) and an
+unsuccessful decode, which is often acceptable.
+
+=item @decoded = $cbor->incr_parse_multiple ($buffer)
+
+Same as C<incr_parse>, but attempts to decode as many CBOR values as
+possible in one go, instead of at most one. Calls to C<incr_parse> and
+C<incr_parse_multiple> can be interleaved.
+
+=item $cbor->incr_reset
+
+Resets the incremental decoder. This throws away any saved state, so that
+subsequent calls to C<incr_parse> or C<incr_parse_multiple> start to parse
+a new CBOR value from the beginning of the C<$buffer> again.
+
+This method can be caled at any time, but it I<must> be called if you want
+to change your C<$buffer> or there was a decoding error and you want to
+reuse the C<$cbor> object for future incremental parsings.
+
+=back
+
 
 =head1 MAPPING
 
@@ -747,7 +816,7 @@
 objects using the C<FREEZE/THAW> methods (the L<Types::Serialier> object
 serialisation protocol). See L<OBJECT SERIALISATION> for details.
 
-=item 28, 29 (shareable, sharedref, L <http://cbor.schmorp.de/value-sharing>)
+=item 28, 29 (shareable, sharedref, L<http://cbor.schmorp.de/value-sharing>)
 
 These tags are automatically decoded when encountered (and they do not
 result in a cyclic data structure, see C<allow_cycles>), resulting in
@@ -767,7 +836,7 @@
 to be supported in the encoder. The decoder, however, will decode these
 values as shared values.
 
-=item 256, 25 (stringref-namespace, stringref, L <http://cbor.schmorp.de/stringref>)
+=item 256, 25 (stringref-namespace, stringref, L<http://cbor.schmorp.de/stringref>)
 
 These tags are automatically decoded when encountered. They are only
 encoded, however, when C<pack_strings> is enabled.
@@ -955,7 +1024,8 @@
 =head1 LIMITATIONS ON PERLS WITHOUT 64-BIT INTEGER SUPPORT
 
 On perls that were built without 64 bit integer support (these are rare
-nowadays, even on 32 bit architectures), support for any kind of 64 bit
+nowadays, even on 32 bit architectures, as all major Perl distributions
+are built with 64 bit integer support), support for any kind of 64 bit
 integer in CBOR is very limited - most likely, these 64 bit values will
 be truncated, corrupted, or otherwise not decoded correctly. This also
 includes string, array and map sizes that are stored as 64 bit integers.
@@ -990,7 +1060,7 @@
       # else either. Whats incredibe over standard strptime totally escapes me.
       # doesn't do fractional times, either. sigh.
       # In fact, it's all a lie, it uses whatever strptime it wants, and of course,
-      # they are all incomptible. The openbsd one simply ignores %z (but according to the
+      # they are all incompatible. The openbsd one simply ignores %z (but according to the
       # docs, it would be much more incredibly flexible indeed. If it worked, that is.).
       scalar eval {
          my $s = $_[1];
@@ -1074,7 +1144,7 @@
 }
 
 sub Time::Piece::TO_CBOR {
-   tag 1, $_[0]->epoch
+   tag 1, 0 + $_[0]->epoch
 }
 
 XSLoader::load "CBOR::XS", $VERSION;