commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claude Warren <cla...@xenei.com>
Subject Re: New Sub-project Proposal.
Date Wed, 11 Sep 2019 17:43:45 GMT
@stain. You have correctly identified the code in my repository.  The code
could be refactored to use streams or we could bring the jena iterator
extensions into commons.  I had suggested that at one time but there were
concerns about conflicts with existing code.  Duplication with of
functionality was the main concern as I recall.

Claude

On Wed, Sep 11, 2019, 09:43 Stian Soiland-Reyes <stain@apache.org> wrote:

> On Wed, 11 Sep 2019 18:12:24 +0200, Gilles Sadowski <gilleseran@gmail.com>
> wrote:
> > > The long and short of this is that there is no good unencumbered open
> > > source library available at the current time.  Myself and several
> others,
> > > in conversation here at ApacheCon, have expressed interest in creating
> such
> > > a library.  We have fairly mature code that we are willing to
> contribute
> > > along with code that embodies new thinking in the bloom filter arena
> (like
> > > proto-bloom filters).  We just need a space within the Apache family to
> > > host it.  The code base seems to small to be a separate project and so
> we
> > > come to Apache Commons seeking a home.
> >
> > IMO, a pretty compelling rationale for hosting it at "Commons".
> > If people think that [Collections] would be the best home, I'd suggest
> > making that component modular; hence unnecessary dependencies
> > would be a non-issue.
>
> Thanks Claude for that brilliant explanation about bloom filter!
> (please blog it!)
>
> At the moment Commons Collections have no runtime dependencies, and only
> 3 test-dependencies.
> <https://github.com/apache/commons-collections/blob/master/pom.xml#L443>
>
> So unless the Bloom filter code comes with any new depdendencies seen to
> "bloat" rest of Commons, it could fit well in there.
>
> It would be a new package "bloom" as it's something to use for building
> collections rather than directly being a collection - but Collections
> already have similar packages for balanced trees, etc.
>
>
> Looking at the code which I suspect is
> <
> https://github.com/Claudenw/BloomFilter/tree/master/src/main/java/org/xenei/bloomfilter
> >
> it looks pretty clean, independent and straight forward to read and
> understand.
>
> From Claude's email I see it is it's *use* that needs explanation!
>
> The only dependencies in that code seem to be within the
> org.xenei.bloomfilter.collections package which currently include use of
> Jena's extended iterator classes.
>
> This could probably be refactored, if this package is also to be
> included? (those classes would also fit naturally into Collections)
>
>
> --
> Stian Soiland-Reyes
> The University of Manchester 🐝
> https://www.esciencelab.org.uk/
> https://orcid.org/0000-0001-9842-9718
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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