plugin framework

[wanderer]

Create a plugin framework.

[kumavis]

hmm plugin framework eh -- sounds anti-pattern :smirk_cat:

[kumavis]

what would plugins do?

[wanderer]

@kumavis plugins would provided things like a websockets-api or a web frontend. I think it should be simple so something like this.

//plugin file
//this is how the plugin starts
exports.start = function(done){

   //do stuff
   done()
}

exports.stop = function(done){
   //do stuff
   done()
}

WDYT?

[kumavis]

so i am missing some context - this project is a full js implementation of... how much of ethereum? ethereumjs-lib claims to be "library of core Ethereum functions." its exports are:

exports.utils = require('./utils');
exports.Network = require('./network');
exports.VM = require('./vm');
exports.Block = require('./block');
exports.Blockchain = require('./blockchain');
exports.Transaction = require('./transaction');
exports.Account = require('./account');
exports.rlp = require('rlp');
exports.Trie = require('merkle-patricia-tree');

So I assume this is the project to handle block mining + transaction confirmation. Anything else? If so, that is all it should do, besides: 1) emit events 2) expose an api

Then a UI can be built on top of this, not in the middle of this -- kind of a hand-wavy distinction perhaps.

[wanderer]

yep you got what does! Another big thing is Upnp & networking stuff, syncing with peers, creating the DBs. Basically ethereumjs-lib implements everything in the yellow paper and node-ethereum implements an ethereum client.

so ultimately I was thinking the UI could be built separately all together. node-ethereum would run as demon talk to the front-end via web-sockets (or whatever transport they want to use)

Also it might be fun to use node-ethereum programmatically. When embedded node-ethereum you don't necessarily want the WebSocket-api.

[kumavis]

some random ideas of how I would expect to be able to use the API

// setup
var eth = require('ethereum')
eth.start() //possibly async
eth.connect('peers.ethereum.org:1337')  // made this up

// setup listeners on wallets / contracts
eth.lookupWallet( myWalletAddress ).on('transaction:incomming', function(){ .. })
eth.lookupContract( myContractAddress ).on('transaction:outgoing', function(){ .. })

// run some experiments offline
eth.disconnect()
var chainBackup = eth.blockChain
var dummyChain = eth.blockChain.clone()
eth.useBlockchain( dummyChain )
eth.evm.execute( testContractSource )
var afterBalance = dummyChain.lookupContract( testContractAddress ).balance()

[wanderer]

yes that is close to how it is now. No wallet functions yet.

App = require('node-ethereum');

//setting hash.
var settings = {
  'upnp': false
 //ect
};

var app = new App(settings);

app.start(function (err) {
  if (err) console.error(err);

  //get a block
  app.blockchain.getBLock(someblockHash, callback);

  //run a transation; updates account balances, run code ect.
  app.state.checkout();
  app.vm.runTx(tx, function(){
    //revert to where we called checkout
    app.state.revert();
    //or instead commit the new state
    app.state.commit();
  });
});

[kumavis]

summary/braindump from skype convo:

Plugins are bad b/c you are enforcing your decisions on other people. Providing an extensive api and emitting events is preferred. One possible desired plugin-like behaviour: adding hooks to override transaction validation. (tho this may be a bad idea for other reasons, e.g. encouraging blockchain fragmentation) Running a full client in the browser is currently too slow to be practical, so we want to provide a remote interface. _The remote interface and the local interface should match._ This allows the ecosystem of modules built on top of node-ethereum to be portable. _This may require making some things async on the local interface that aren't otherwise required to be_, just to ensure consistency for remote + local. The remote interface would handle RPC and event emitting (perhaps https://github.com/substack/dnode + https://github.com/pgte/duplex-emitter). The consumer would handle wiring (e.g connecting the local and remote streams). However, To make the remote a little more "drop-in" friendly, and have less of an expectation of use in the npm ecosystem, we can provide some auto-wiring by bundling it with websocket-stream and accepting a websocket target.

did i miss anything

[wanderer]

sounds good. I'm removing plugins as a need feature. I still want to have the option to support different transports for the RPC api. But I think I can just make the an configurable option if it is needed.