diff options
| author | Mike Hearn <mike@plan99.net> | 2013-07-15 17:48:41 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-07-15 15:48:48 +0000 |
| commit | d168111eb65cb519794ecb7853b45248ada8c559 (patch) | |
| tree | 11f2a1b6f95440a95ef6cc4b80b3fccb4ef9adf5 | |
| parent | ae31c4ba4faa7e63cc6c478c652c0aab4e24d63a (diff) | |
| download | pi-bitcoindev-d168111eb65cb519794ecb7853b45248ada8c559.tar.gz pi-bitcoindev-d168111eb65cb519794ecb7853b45248ada8c559.zip | |
Re: [Bitcoin-development] Introducing BitcoinKit.framework
| -rw-r--r-- | 81/d732a4fda6a894599a7f2fee49f219085ef736 | 253 |
1 files changed, 253 insertions, 0 deletions
diff --git a/81/d732a4fda6a894599a7f2fee49f219085ef736 b/81/d732a4fda6a894599a7f2fee49f219085ef736 new file mode 100644 index 000000000..21b1608c0 --- /dev/null +++ b/81/d732a4fda6a894599a7f2fee49f219085ef736 @@ -0,0 +1,253 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1Uyl16-0003QQ-HF + for bitcoin-development@lists.sourceforge.net; + Mon, 15 Jul 2013 15:48:48 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.219.49 as permitted sender) + client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com; + helo=mail-oa0-f49.google.com; +Received: from mail-oa0-f49.google.com ([209.85.219.49]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Uyl14-0004jk-OR + for bitcoin-development@lists.sourceforge.net; + Mon, 15 Jul 2013 15:48:48 +0000 +Received: by mail-oa0-f49.google.com with SMTP id n9so15758103oag.36 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 15 Jul 2013 08:48:41 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.60.41.37 with SMTP id c5mr43552352oel.43.1373903321312; Mon, + 15 Jul 2013 08:48:41 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.23.36 with HTTP; Mon, 15 Jul 2013 08:48:41 -0700 (PDT) +In-Reply-To: <C1727B41-AF61-44FA-BE17-5FE4425FDEA8@grabhive.com> +References: <B87F1213-5BD8-43F5-9744-F69947561ED5@grabhive.com> + <CANEZrP2xh=m8yWLt-o2UrrUVfU+cUYBuMVxkVFF5mVMtWdRwOQ@mail.gmail.com> + <C1727B41-AF61-44FA-BE17-5FE4425FDEA8@grabhive.com> +Date: Mon, 15 Jul 2013 17:48:41 +0200 +X-Google-Sender-Auth: FS2iKXXn7zmRA_Xpk90SH_55mnk +Message-ID: <CANEZrP0_H9+prDSF92q8a4QzP=fzDM6cTDv0+KcfV9NF9thkmw@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Wendell <w@grabhive.com> +Content-Type: multipart/alternative; boundary=089e013a09646c362d04e18ecb94 +X-Spam-Score: -0.5 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (mh.in.england[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1Uyl14-0004jk-OR +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Introducing BitcoinKit.framework +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 15 Jul 2013 15:48:48 -0000 + +--089e013a09646c362d04e18ecb94 +Content-Type: text/plain; charset=UTF-8 + +Oracle provide an OSX JVM and will do so for the forseeable future, it's +also open source, so the community could carry on if they stopped. The +primary problem with the Oracle JVM is lack of retina support for Swing, +but if you'd write a Cocoa UI yourself then it doesn't matter of course as +Java won't handle any GUI stuff. Retina support for JavaFX2 (the +current-gen gui toolkit) is available in Java 8 so it's definitely being +actively developed, it's not abandoned or anything. + +So the question then becomes, which is better: + +a) Take bitcoinj completely out of the Java world via native compilation or +transpilation to C++ +b) Embed the JVM and link the two worlds together? + +(b) is much less ambitious, especially if you're OK with writing a bit of +Java code to keep the interface thin. Basically the Java side calls into +your app when interesting user-visible things happen, like new transactions +appearing, then your GUI can call into the java side to send money. There +are auto-translators that make the glue work easy, like +https://code.google.com/p/javacpp/. You probably wouldn't want to expose +the entire bitcoinj API that way because it's very large, but the code +needed to bring up a wallet app is very small. I knocked one up this +weekend in about one evenings worth of coding, completed with nice +animations. The interfaces you'd need are basically some Objective-C++ +methods that receive information from the Bitcoin side, like the balance +having changed, a list of transactions, etc, and then a callback into the +Java side to send money. If you look at the javacpp site you can see +example code for making calls both ways. + +If I were in your shoes, I'd go for (b) because it is the most well trodden +path and will let you achieve the best user visible results quickly. The +JVM can be bundled with your app and stripped down if you're worried about +download size. + +If it's unclear how the code would look, let me know and I'll try and knock +up a really simple prototype. + +There's also (a). I'm investigating transpilation for a few reasons, one of +which is to do with a private project. I'm working with the author of j2c: +https://code.google.com/a/eclipselabs.org/p/j2c/. It's a rather +sophisticated transpiler that converts Java to clean, readable C++11 that +looks much like code a human would write. It's complete enough to transpile +the entire standard Java class library, including all the GUI toolkits and +other things - so, pretty amazing piece of code. However it's incomplete +because where the Java code calls native methods (that would be provided by +the JVM) it just spits out stubs you're expected to fill out yourself, for +starting threads and so on. As there's no JVM it's just like using a C++ +library that is missing a "portability layer". + +I'm working on this myself and don't really need much help at the moment, +I'm just making steady progress towards getting something up and running. I +can let you know once I reach some interesting milestones. The point of +this is that whilst you don't need access to most of the API to write a +wallet app, I'd like to make every kind of app easy from C++, not just GUI +wallets. Then the compile-to-C++ approach is much more appealing, even +though it's also more work. + + + + + +On Mon, Jul 15, 2013 at 4:39 PM, Wendell <w@grabhive.com> wrote: + +> Hi Mike, +> +> You are absolutely right about the synchronize time, it's one of our main +> frustration points right now and we clearly won't deliver the kind of user +> experience we want, without fixing this. Actually we were thinking of +> extending Jeff Garzik's picocoin as time permits, but the plan is far from +> concrete at the moment. +> +> What you say about trans-piling bitcoinj is _really_ appealing. We +> discounted Java simply because an OS X JVM is no longer guaranteed, but +> otherwise bitcoinj is ideal for our purposes. How can we assist or +> otherwise accelerate such an effort? +> +> -w +> +> On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote: +> +> > That's great! I'm all for more wallets, especially user friendly UIs. +> > +> > However being based on bitcoind means it will take a very long time to +> synchronize for new users. We know a lot of users drop out. The best fix +> for this is SPV mode. Do you have any plans in this direction? +> > +> > So far, the only SPV mode implementation I know about is bitcoinj. I am +> experimenting with trans-piling bitcoinj to C++ to make it usable from +> Objective-C++ exactly with your use case in mind. +> +> + +--089e013a09646c362d04e18ecb94 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Oracle provide an OSX JVM and will do so for the forseeabl= +e future, it's also open source, so the community could carry on if the= +y stopped. The primary problem with the Oracle JVM is lack of retina suppor= +t for Swing, but if you'd write a Cocoa UI yourself then it doesn't= + matter of course as Java won't handle any GUI stuff. Retina support fo= +r JavaFX2 (the current-gen gui toolkit) is available in Java 8 so it's = +definitely being actively developed, it's not abandoned or anything.<di= +v> +<br></div><div>So the question then becomes, which is better:</div><div><br= +></div><div>a) Take bitcoinj completely out of the Java world via native co= +mpilation or transpilation to C++</div><div>b) Embed the JVM and link the t= +wo worlds together?</div> +<div><br></div><div>(b) is much less ambitious, especially if you're OK= + with writing a bit of Java code to keep the interface thin. Basically the = +Java side calls into your app when interesting user-visible things happen, = +like new transactions appearing, then your GUI can call into the java side = +to send money. There are auto-translators that make the glue work easy, lik= +e=C2=A0<a href=3D"https://code.google.com/p/javacpp/">https://code.google.c= +om/p/javacpp/</a>. You probably wouldn't want to expose the entire bitc= +oinj API that way because it's very large, but the code needed to bring= + up a wallet app is very small. I knocked one up this weekend in about one = +evenings worth of coding, completed with nice animations. The interfaces yo= +u'd need are basically some Objective-C++ methods that receive informat= +ion from the Bitcoin side, like the balance having changed, a list of trans= +actions, etc, and then a callback into the Java side to send money. If you = +look at the javacpp site you can see example code for making calls both way= +s.</div> +<div><br></div><div>If I were in your shoes, I'd go for (b) because it = +is the most well trodden path and will let you achieve the best user visibl= +e results quickly. The JVM can be bundled with your app and stripped down i= +f you're worried about download size.=C2=A0</div> +<div><br></div><div>If it's unclear how the code would look, let me kno= +w and I'll try and knock up a really simple prototype.</div><div><br></= +div><div>There's also (a). I'm investigating transpilation for a fe= +w reasons, one of which is to do with a private project. I'm working wi= +th the author of j2c:=C2=A0<a href=3D"https://code.google.com/a/eclipselabs= +.org/p/j2c/">https://code.google.com/a/eclipselabs.org/p/j2c/</a>. It's= + a rather sophisticated transpiler that converts Java to clean, readable C+= ++11 that looks much like code a human would write. It's complete enough= + to transpile the entire standard Java class library, including all the GUI= + toolkits and other things - so, pretty amazing piece of code. However it&#= +39;s incomplete because where the Java code calls native methods (that woul= +d be provided by the JVM) it just spits out stubs you're expected to fi= +ll out yourself, for starting threads and so on. As there's no JVM it&#= +39;s just like using a C++ library that is missing a "portability laye= +r".</div> +<div><br></div><div>I'm working on this myself and don't really nee= +d much help at the moment, I'm just making steady progress towards gett= +ing something up and running. I can let you know once I reach some interest= +ing milestones. The point of this is that whilst you don't need access = +to most of the API to write a wallet app, I'd like to make every kind o= +f app easy from C++, not just GUI wallets. Then the compile-to-C++ approach= + is much more appealing, even though it's also more work.</div> +<div><br></div><div><br></div><div><br></div></div><div class=3D"gmail_extr= +a"><br><br><div class=3D"gmail_quote">On Mon, Jul 15, 2013 at 4:39 PM, Wend= +ell <span dir=3D"ltr"><<a href=3D"mailto:w@grabhive.com" target=3D"_blan= +k">w@grabhive.com</a>></span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex">Hi Mike,<br> +<br> +You are absolutely right about the synchronize time, it's one of our ma= +in frustration points right now and we clearly won't deliver the kind o= +f user experience we want, without fixing this. Actually we were thinking o= +f extending Jeff Garzik's picocoin as time permits, but the plan is far= + from concrete at the moment.<br> + +<br> +What you say about trans-piling bitcoinj is _really_ appealing. We discount= +ed Java simply because an OS X JVM is no longer guaranteed, but otherwise b= +itcoinj is ideal for our purposes. How can we assist or otherwise accelerat= +e such an effort?<br> + +<span class=3D"HOEnZb"><font color=3D"#888888"><br> +-w<br> +</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> +On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:<br> +<br> +> That's great! I'm all for more wallets, especially user friend= +ly UIs.<br> +><br> +> However being based on bitcoind means it will take a very long time to= + synchronize for new users. We know a lot of users drop out. The best fix f= +or this is SPV mode. Do you have any plans in this direction?<br> +><br> +> So far, the only SPV mode implementation I know about is bitcoinj. I a= +m experimenting with trans-piling bitcoinj to C++ to make it usable from Ob= +jective-C++ exactly with your use case in mind.<br> +<br> +</div></div></blockquote></div><br></div> + +--089e013a09646c362d04e18ecb94-- + + |