On Tue, Aug 8, 2017 at 7:50 PM, Christopher <ctubb...@apache.org> wrote: > On Tue, Aug 8, 2017 at 1:33 PM Keith Turner <ke...@deenlo.com> wrote: > >> On Fri, Aug 4, 2017 at 4:42 PM, Christopher <ctubb...@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. >> >> > It was my intention to put some effort into this this week, but I don't > mind collaborating. I just don't want to be stuck doing only reviews. :)
I'll wait for your initial PR to the repo. Let me know if you want help with anything before then. > > > >> > 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. >> >> > +1; do you have a link to that discuss thread? I'm not familiar with this, > and was not a participant. http://mail.openjdk.java.net/pipermail/discuss/2016-November/004062.html > > >> > >> > 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. >> >> > +1 > > >> > >> > 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. >> >> > +1; it sounds like you've already got the README half written ;) An extremely rough outline is half written. > > >> > 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/ >>
