Mailing-List: contact dev-help@fluo.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@fluo.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CAL5zq9b7N1sZagKsErRCwnTqQTB-sZf5MS=gB7N96t_dECowyA@mail.gmail.com>
References: <CAL5zq9b7N1sZagKsErRCwnTqQTB-sZf5MS=gB7N96t_dECowyA@mail.gmail.com>
From: Keith Turner <keith@deenlo.com>
Date: Tue, 8 Aug 2017 13:32:57 -0400
Message-ID: <CAGUtCHrN9t4O=kkHEvAOmsQ8qxkfsfD5Ahdv+0iqtCQn5r1J9g@mail.gmail.com>
Subject: Re: About fluo-bytes
To: dev@fluo.incubator.apache.org
Content-Type: text/plain; charset="UTF-8"
archived-at: Tue, 08 Aug 2017 17:33:10 -0000

On Fri, Aug 4, 2017 at 4:42 PM, Christopher <ctubbsii@apache.org> wrote:
> Fluoers,
>
> I created a fluo-bytes repository in GitBox[1], so we can try to create a

This is great. I will take a stab at putting together the initial PR
for the repo unless someone else was interested.

> dependency-free, standalone implementation of the basic Bytes features we
> need, based on Keith's observations in his blog post[2].

At some point we need to circle back to the openjdk discuss list and
let them know we are working on this.  There were a few people there
who expressed interest in a project like this.  Maybe we can do that
after we get the basic readme and initial import up. Reading this post
made me think of the readme a lot.

>
> Over the next few weeks, I'd like to try to start using it to create a
> small library of the following:
>
> * A ByteSequence interface (analogous to CharSequence)
> * BytesBuilder (analogous to StringBuilder)
> * an immutable Bytes implementation of ByteSequence (analogous to String)
>
> Maybe later, we can add useful InputStream and OutputStream implementations
> and other useful tools, but it should always be a small library with a
> narrow focus on manipulating byte sequences.
>
> The idea is that this will be semver, but will very strong prefer to avoid
> ever going to a breaking 2.0 change, instead insuring it will be backwards
> compatible for a *LONG* time, making it safe for use in other projects'
> APIs.

When creating the readme, it would be good to try to explain the
rational for avoiding dropping methods.  I attempted that in my blog
post, but not sure how well I did at getting the point across.  I
think it would be best shown with an example that shows how it can be
hard to use two projects where one uses newer methods and another uses
older dropped methods.  Couple that with both projects having the
library in their API and its a huge headache for any users of both
libraries.

>
> I think this library would be useful not only for Fluo's API, but as a
> separate dependency-free library, it could be easily reused by many other

We will also need to explain why dependencies are so important.  If
their were dependencies they would also need to follow very strict API
guarantees.  Having Java standard libs as the only dep is good because
Java itself is very rigorous about its API.

Another thing that will need to be explained well in the readme is the
benefit of multiple APIs using the same immutable type, it avoids
copies when going between APIs.

> projects, such as Accumulo (and anybody else).
>
> [1]: https://github.com/apache/fluo-bytes
> [2]: https://fluo.apache.org/blog/2016/11/10/immutable-bytes/