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. Claude On Thu, Sep 12, 2019 at 9:28 AM Stian Soiland-Reyes <st...@apache.org> wrote: > On Thu, 12 Sep 2019 08:06:59 +0100, Claude Warren <cla...@xenei.com> > 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 https://github.com/apache/commons-collections/ 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 > https://orcid.org/0000-0001-9842-9718 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
