commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claude Warren <>
Subject Re: New Sub-project Proposal.
Date Thu, 12 Sep 2019 15:13:44 GMT
I have no issues with contributing Span and SpanBuffer.  Span is similar to
commons-lang Range and it might be reasonable to migrate to Range for the
Span part.  The SpanBuffer (possibly renamed to RangeBuffer) is
conceptually a byte buffer with long offset and length so that it can
conceptually be shifted.  A span buffer can be composed of multiple buffers
and you can extract span buffers from other span buffers.  Like the
standard java bytebuffer they do not reallocate the space, just point to
the offsets in the existing allocated space.  It is the composition that
makes them powerful.

So I can create a SpanBuffer from "Hello World", and another from "Goodbye
cruel"  Then I can compose a new one by creating one useing the "Goodbye
cruel" and folloiwng it with the "Hello World".cut( 5 ) [ cut the first 5
bytes off] and have "Goodbye cruel world" as the result.  This structure is
very handy when serializing large objects across kafka and similar systems
where the buffer size may be smaller than the object you want to serialize
as it can be chopped into smaller chunks, and reassembled as a composition
of the smaller chunks without the calling classes knowing.  I also used it
when I built a binary diff routine that handles very large files as it
means that I only need keep the one file and the differences to the other.

But Span and SpanBuffer are both used in the serialization classes that
could form the basis of example code, so accepting them is optional.


On Thu, Sep 12, 2019 at 9:28 AM Stian Soiland-Reyes <>

> On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren <>
> wrote:
> > Actually the code I was thinking of is the multi-filter branch.  It
> cleans
> > up some names and simplifies a few things.  The collections and storage
> > packages might be best added as examples rather than as mainline code.
> >
> > In this case we just provide the bloom filter implementation,  If we want
> > to provide the container implementation then I think it should probably
> be
> > modified to accept any SortedSet or NavigatableSet in the constructor.
> >
> > When I return home, next week, I'll take a swipe at moving the packages
> > over to org.apache.commons.collections4.bloomfilter package (unless there
> > is a better package name).  We can then look at the entire code donation
> > and decide what changes need to be made before it is accepted.
> >
> > Does this sound like a reasonable approach?
> Sounds reasonable to me - then it's easy to see what will be the code
> donation, they could be examples at first that we can link to from
> documentation, several commons packages have such example codes.
> Perhaps use packagename "commons.collections4.bloomfilter" without
> org.apache before it's been IP-cleared? Alternatively add it on a fork
> of so we don't confuse
> anyone.
> I see on your branch you are using some new dependencies like
> org.xenei.blockstorage and org.xenei.spanbuffer.SpanBuffer - would these
> be needed as well if we include the container implementation or are they
> more for disk-based collections?
> --
> Stian Soiland-Reyes
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

I like: Like Like - The likeliest place on the web

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message