I fail to see why you would want to embed the library. However Ocaml and Haskell can also be compiled to whatever architucture you need, and you can't beat JCM for portability.
I'm just saying it would help trust the official client if it used a statically typed, funcitonal programming language. A more "mathematical" one, if you like. For me, in the official client at least, it should be about using the safest technologies.
Topic: Proposal for a C bitcoin library. - page 2. (Read 8366 times)
You still need to compile or interpret the code on different platforms. C is widely accepted among platforms. In the future there may even be bitcoin software on microcontrollers where people can make bitcoin payments with card readers where their wallet information is encrypted on a card (You wouldn't store all the money on a card in case you lost it of-course and this is just an example).
Also, I was looking into making an objective-c implementation of bitcoin but I can't do that with the current state of the software. If there was a c library, I could make objective-c classes for bitcoin and use it to make Mac and iOS bitcoin clients with Apple's APIs.
I'm not clever enough to convert the bitcoin code and don't use C++. I wouldn't be mentally equipped to make a c library, only propose it as an idea.
Also, I was looking into making an objective-c implementation of bitcoin but I can't do that with the current state of the software. If there was a c library, I could make objective-c classes for bitcoin and use it to make Mac and iOS bitcoin clients with Apple's APIs.
I'm not clever enough to convert the bitcoin code and don't use C++. I wouldn't be mentally equipped to make a c library, only propose it as an idea.
Now that mining is a miner's thing, I think that what we need is an official Haskell / ocaml / scala library and client. Something where checking what's going on is a bit easier. Also this way we wouldn't have to worry about a worm wiping clean the bitcoin network through a stupid buffer overflow. I only run the client when necessary because of this.
C bindings can be created from these.
C bindings can be created from these.
Hello. 
I was talking about bitcoin on the development irc channel last night. I was asking about various things relating to making a bitcoin client for mobile devices. People on the channel seemed to support my thoughts that the bitcoin source code needs to be improved a lot.
I like bitcoin and I would like it to spread. For it to be spread, it needs to be easily accessible for programmers to use and apply it to various devices. I have a proposal for a new way of organising the bitcoin software using a C library.
The current bitcoin source code contains the code for the entire bitcoin client. The back-end needs to be completely separated from the UI and platform specific parts. Using a library which programmers can include in their projects and easily attach to their UI code, makes much more sense.
Bitcoin requires platform specific code. I'm not fully aware of what it requires exactly. Obviously, it needs access to the internet through irc sockets.
I suggest the library does not implement platform specific code and instead requires the user to implement functions. The user can send function pointers to bitcoin which do some of the platform specific work. For example, bitcoin may need to send a message though an IRC socket. The programmer can implement a function which takes an ID argument and a data argument and sends it over the socket (defined by the ID allowing multiple socket objects, if needed) using the platform specific APIs. This way bitcoin is as portable as possible without anyone needing to modify the library, only understand how to use it. Function pointers are a sensible way to do this. Function pointers could also be used for event handling (Events for receiving bit coins etc.).
Bitcoin is currently written in C++. I think this is a poor choice. C is more popular than C++ according to surveys (http://langpop.com/) and is generally more portable. C++ programmers can easily use it and programmers using other C based languages like Objective-C and C# can also integrate C. C can easily be accessed by other languages on many platforms. While C++ is also widely portable, C is a better alternative offering ultimate portability. C is widely used on many processor architectures. If bitcoin was ever to make it's way into a variety of devices and products, C is the best way to go.
A C++ wrapper would be lovely but the fundamental library should be in C. The library should be done in standard C of-course, only using libraries that are portable with standard c.
To conclude my proposal is to separate the back-end code for bit-coin into a C library which can be used by programmers to easily create bitcoin applications, removing all UI and platform specific code from the core library.
What do people think about this?
I was talking about bitcoin on the development irc channel last night. I was asking about various things relating to making a bitcoin client for mobile devices. People on the channel seemed to support my thoughts that the bitcoin source code needs to be improved a lot.
I like bitcoin and I would like it to spread. For it to be spread, it needs to be easily accessible for programmers to use and apply it to various devices. I have a proposal for a new way of organising the bitcoin software using a C library.
The current bitcoin source code contains the code for the entire bitcoin client. The back-end needs to be completely separated from the UI and platform specific parts. Using a library which programmers can include in their projects and easily attach to their UI code, makes much more sense.
Bitcoin requires platform specific code. I'm not fully aware of what it requires exactly. Obviously, it needs access to the internet through irc sockets.
I suggest the library does not implement platform specific code and instead requires the user to implement functions. The user can send function pointers to bitcoin which do some of the platform specific work. For example, bitcoin may need to send a message though an IRC socket. The programmer can implement a function which takes an ID argument and a data argument and sends it over the socket (defined by the ID allowing multiple socket objects, if needed) using the platform specific APIs. This way bitcoin is as portable as possible without anyone needing to modify the library, only understand how to use it. Function pointers are a sensible way to do this. Function pointers could also be used for event handling (Events for receiving bit coins etc.).
Bitcoin is currently written in C++. I think this is a poor choice. C is more popular than C++ according to surveys (http://langpop.com/) and is generally more portable. C++ programmers can easily use it and programmers using other C based languages like Objective-C and C# can also integrate C. C can easily be accessed by other languages on many platforms. While C++ is also widely portable, C is a better alternative offering ultimate portability. C is widely used on many processor architectures. If bitcoin was ever to make it's way into a variety of devices and products, C is the best way to go.
A C++ wrapper would be lovely but the fundamental library should be in C. The library should be done in standard C of-course, only using libraries that are portable with standard c.
To conclude my proposal is to separate the back-end code for bit-coin into a C library which can be used by programmers to easily create bitcoin applications, removing all UI and platform specific code from the core library.
What do people think about this?
Jump to: