Re: [hyperledger/fabric] Remove chaincode instance variables from example chaincodes (#1981)

Brian Behlendorf <bbehlendorf@...>

Great, didn't see the "help wanted" tag before.  Is it documented in the Wiki for first-time devs to see?

I am not a huge fan of the bot idea, as I think it should be something the devs do in the moment and second-nature, e.g. "oh, this seems like a broader issue, I should seek broader input on it", as stuff can and should move quickly rather than wait for the weekly bot.

Would love to sync with Sawtooth Lake on these practices too.


On 06/24/2016 10:42 AM, Sheehan Anderson wrote:

Hi Brian

Completely agree that it's a firehose at this point and too much information for a person to reasonably track. While I believe GitHub issues are the best place to hold discussions, I recognize the same "how to surface the architecture conversations" problem. I've seen a few major open source projects on GitHub use a "big picture" label on important issues. Perhaps we could use the same label and write a bot that collects these once per week and sends a collection of links to the mailing list? People could then subscribe to those particular issues and receive updates via email.

We do have a "help wanted" label ( which is similar to the "bite-sized" marker that you describe. So far this has worked quite well and a lot of people have used it to pick up work.


Brian Behlendorf ---06/24/2016 03:25:09 AM---So I've been following the firehose from watching the github issues (feeling foolish for not lookin

From: Brian Behlendorf <bbehlendorf@...>
To: hyperledger-fabric@...
Date: 06/24/2016 03:25 AM
Subject: [Hyperledger-fabric] Fwd: Re: [hyperledger/fabric] Remove chaincode instance variables from example chaincodes (#1981)
Sent by: hyperledger-fabric-bounces@...

So I've been following the firehose from watching the github issues (feeling foolish for not looking there before) and am loving all the activity.  I am concerned, though, that sometimes important architectural conversations get buried in a message that only crazy people like me, and those working specifically on the code in question, are likely to see.  The below is an example (not to pick on anyone in particular).  Follow the link at the bottom for the full thread.  I know there is corresponding conversation going on in the Slack channel too, especially when there's some disagreement.  But I'm wondering if devs could do a better job of surfacing architecture and deeper implementation conversation & thinking to this list from time to time, like the topic below, as a way to tap into the broader Fabric dev community for what people think, as well as help folks following along start to get into the rhythm of how the code works.  Thoughts?

Oh, this also reminds me of one of Karl Fogel's best pieces of advice, something he and others did on the Subversion project.  When there were triaged bugs that we unresolved, but were assessed by developers as likely to not require siginificant rearchitecture of the code to solve, but instead are more likely a simple error, then those issues were marked as "bite-sized", a signal to new developers that they may want to use these issues as a good learning experience while the older hands on the project were focused on the harder issues.  Thought on that too?


-------- Forwarded Message --------
Re: [hyperledger/fabric] Remove chaincode instance variables from example chaincodes (#1981)
Thu, 23 Jun 2016 21:02:22 -0700 (PDT)
Brian Behlendorf <brian@...>
Thu, 23 Jun 2016 15:49:49 -0700
Bishop Brock <notifications@...>
hyperledger/fabric <reply+000a22e303a4865b06b3355cca97b78d11214047c178349a92cf000000011384298d92a169ce09a851a2@...>
hyperledger/fabric <fabric@...>

I would agree that in general, simple example chaincodes should not use persistent state. However, even though there was a bug in the busywork chaincode that caused unexpected non-determinism, I'm not sure I'm ready to banish chaincode-local state for chaincodes that are specifically designed as test programs. For example, one of the planned future capabilities for busywork was to allow non-deterministic error injection, which would make use of chaincode-local state. (A single chaincode instance is passed information via a query targeting its peer, and on the next invoke that chaincode instance stores a random or know-bad value, for example.)

There may also be optimizations for test programs (or even non test programs?) that require some knowledge of what is expected in the state, and perhaps cause information to be reloaded from the state when is there is a mismatch.I was actually planning to add something like this in the next busywork chaincode I've been thinking about. This chaincode loads a very large data structure and its version number when the chaincode starts. On each invoke, it compares the latest version number (8 bytes) from the state with its own cached version number, and only reloads the large state if they disagree. Obviously the version number is also updated whenever the large state is modified (which will be a rare event).

In general, in Go anyway, I don't think you can stop anyone from storing data in a package-global variable, and then accessing the variable, even if you make each chaincode invocation a newly-created object. It is certainly unacceptable to take the drastic step to reload the chaincode package binary every time the chaincode is invoked (assuming Go supported that, which I don't think it does currently). There is also the file system, network devices, and other ways to store and access persistent data. Unless we go to a domain-specific language.

You are receiving this because you are subscribed to this thread.
Reply to this email directly,
view it on GitHub, or mute the thread.

Hyperledger-fabric mailing list

Hyperledger-fabric mailing list

Brian Behlendorf
Executive Director at the Hyperledger Project
Twitter: @brianbehlendorf

Join to automatically receive all group messages.