Hay Sean, thanks for your reply and your feedback <3
> For the applications/projects I've seen so far, I see no need for it to be a separate project. Other projects could submit unit tests and pull requests where appropriate, but if it's in a Maven repo as a separate JAR, that's all they need. In either case, a submodule would be the least disruptive way to start. As I said earlier, I am not that deep into the bitcoinj project, but what I have seen so far is that the releases of bitcoinj follow the bitcoin-core version. This makes a lot of sense and helps your users to understand which version of bitcoinj is needed for the bitcoin version. But when providing a library for multiple chains, which all have different release cycles and different needs, it may not be the best idea to let this new core library have the same release cycle as bitcoinj. If you take a look at Docker and Kubernetes as an example: Kubernetes was based on Docker for a long time, but they faced the same problem: They carried a lot of Docker code while not using it all. So together with the Docker guys, they decided to create "libcontainer" which both projects now use as a base. Libcontainer has its own release cycle so that when the Kubernetes guys need a change really urgend, a new version can be released without forcing the docker guys to do a new release too. So in our case: Let's say the Steem devs decide to calculate the Base58Checksum in a different way. Following your current suggestion it would mean that I submit a pullrequest to the new bitcoinj module and then I have to wait for your release until I can update my project. Due to the low number of bitcoin releases I may have to wait months until my change is finally available. Using a separate project it would allow us to do a new "core" release - I could update SteemJ to the new version including my changes while the bitcoinj project can stay on the old version and without being forced to do a new relase only for me changes. Please don't get me wrong - I do not want to push my own repo/project here - I only want to point out why I think it would be better to have a separate library. ____________________________________ As we all seem to agree that this a good idea in general I want to ask again how we can continue / push this? As I would love to see this maintained by the bitcoinj team who has for sure the most knowledge and the biggest community, I am still "voting" for a separate project as explained above. Could you maybe setup a new repo for this? Beside that: Do you guys have some connections to other "api wrapper" devs? I've tried to contact the ethereumj guys in their chat, but received no answer so far. I would love to have as much people as possible involved :) Thank you once again for your feedback and the discussion in general. Best regards! Am Mittwoch, 10. Januar 2018 07:56:05 UTC+1 schrieb Sean Gilligan: > > I personally think a a sub-module is a great approach. > > For the applications/projects I've seen so far, I see no need for it to > be a separate project. Other projects could submit unit tests and pull > requests where appropriate, but if it's in a Maven repo as a separate > JAR, that's all they need. In either case, a submodule would be the > least disruptive way to start. > > Marvin has clearly worked this through much further than I have -- I've > mostly needed subclasses of `MainNetParams` with different > `addressHeader` values and it would be nice to get this without pulling > in all of bitcoinj-core. I'm not sure what Jeremy Rand needs or has been > pulling from libdohj. > > Even for some of the mostly Bitcoin-focused components of ConsensusJ, it > would be nice to be able to get some of the core bitcoinj types (e.g. > Address, Sha256Hash, ECKey) without getting the transitive networking > dependencies, etc. > > So I really like the idea of a base or types submodule -- even > independent of support for pluggable coin types. > > -- Sean > > > > > > > On 1/5/18 7:30 AM, Andreas Schildbach wrote: > > I'm not against this idea, but it can be quite some work and potentially > > be disruptive on the API. > > > > We could probably start by a submodule in bitcoinj and once that > > stabilizes it could be extracted to a separate project. > > > > > > On 12/12/2017 01:30 AM, Sean Gilligan wrote: > >> Hi Marvin, > >> > >> Sorry for not responding sooner. We have a need for something like this > >> in the ConsensusJ [0] project (formerly called bitcoinj-addons) and > were > >> thinking about making a proposal similar to yours. You can see some of > >> the discussion on Issue #14 [1] and Issue #25 [2]. We've dabbled with > >> Litecoin, Namecoin, and a couple of other chains - -and there's some > >> significant Namecoin work that JeremyRand wants to merge. JeremyRand > has > >> been using and brought to my attention the libdohj [3] (pronounced "lib > >> doge" -- like the coin) which addresses some of these issues. > >> > >> The ideal solution IMO would be for bitcoinj to split of some of these > >> foundational classes into a separate jar (smaller and with fewer > >> dependencies than bitcoinj-core) that can be used by bitcoinj and other > >> chains. I haven't had much time lately to look at the latest > >> alternatives, but would love to see a great, standard, open source > >> solution for some common code. > >> > >> -- Sean > >> > >> [0] https://github.com/ConsensusJ/consensusj > >> [1] https://github.com/ConsensusJ/consensusj/issues/14 > >> [2] https://github.com/ConsensusJ/consensusj/issues/25 > >> [3] https://github.com/dogecoin/libdohj > >> > >> > >> On 12/11/17 12:00 PM, Marvin wrote: > >>> I've started to setup a repo for this > >>> idea: https://github.com/marvin-we/crypto-core > >>> > >>> Am Sonntag, 3. Dezember 2017 10:44:41 UTC+1 schrieb Marvin: > >>> > >>> Hello together, > >>> > >>> I initially created the following ticket: > >>> https://github.com/bitcoinj/bitcoinj/issues/1486 > >>> <https://github.com/bitcoinj/bitcoinj/issues/1486> And was asked > >>> to publish this idea on the mailing list - So I hope this group is > >>> the right place :) > >>> > >>> _____________________ > >>> > >>> Original Ticket: > >>> > >>> Hello together and a big thanks for providing this library. > >>> > >>> I have the follownig "feature" request: > >>> > >>> I develop a Java-Library for the > >>> [Steem-Blockchain](https://github.com/steemit/steem/ > >>> <https://github.com/steemit/steem/>) called > >>> [SteemJ](https://github.com/marvin-we/steem-java-api-wrapper > >>> <https://github.com/marvin-we/steem-java-api-wrapper>) and I try > >>> to reuse as much parts of bitcoinJ as possible - Why? Because this > >>> project is well documented, the code quality is really great and > >>> the lib itself is bulletproof. > >>> > >>> A lot of your implementations (e.g. the ECKey object or the Utils > >>> class) provide functionallities required in nearly all Blockchain > >>> libs out there. Due to that a lib developer has three options: > >>> > >>> 1. Implement something on his/her own (e.g. IOTA) > >>> 2. Use the whole bitcoinJ project (e.g. SteemJ) > >>> 3. Copy your code (e.g. EtheriumJ) > >>> > >>> I guess number one can be pretty time consuming as it will require > >>> a lot of time until the developer gained the knowledge that you > >>> already have and will also not reach the code quality you offer. > >>> > >>> Number two is what I am currently doing. This solution has one > >>> disadvantage: I need to add the whole BitcoinJ library while only > >>> using some specific classes. > >>> > >>> Number three solves this problem, but you manually need to take > >>> care of updates and merge those changes. > >>> > >>> So I was wondering if it would be possible to put classes that are > >>> not bitcoin specific into a separate package? > >>> > >>> _____________________ > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups "bitcoinj" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > >>> an email to [email protected] <javascript:> > >>> <mailto:[email protected] <javascript:>>. > >>> For more options, visit https://groups.google.com/d/optout. > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "bitcoinj" group. > >> To unsubscribe from this group and stop receiving emails from it, send > >> an email to [email protected] <javascript:> > >> <mailto:[email protected] <javascript:>>. > >> For more options, visit https://groups.google.com/d/optout. > > > > -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
