Topic: NXT :: descendant of Bitcoin - Updated Information - page 773. (Read 2761637 times)
We should send another BTC
130 minutes till deadline
warning to the rush in the last minutes, only 0,05btc from 2nd
My current setup is that i use embedded jetty and feed the Nxt servlet on startup to jetty.
What's the setup you use for jetty? Will i still need to embed my own or will 0.8.0 take care of that?
You shouldn't need to deal with jetty directly. You call Nxt.init() which will trigger all initializations, and will start the jetty servlets it needs (if nxt.shareMyAddress=false, it will not start the PeerServlet, if nxt.enableUIServer=false it will not start the UserServlet for the NRS UI), and is safe to call multiple times. Then, there will be Nxt.getBlockchain(), Nxt.getBlockchainProcessor() and Nxt.getTransactionProcessor() to get hold of the corresponding singletons. The init adds a shutdownHook to handle stopping the threads and closing the database at the jvm shutdown, I assume you never need to shutdown it explicitly once started until the application exit.What's the setup you use for jetty? Will i still need to embed my own or will 0.8.0 take care of that?
That's a lot of changes I am going through, so 0.8.0e should come out some time next week, and I will have to keep it compatible with 0.7.6 peers until client packagers and developers transition to 0.8.0.
130 minutes till deadline
McDoxy,
Deposit to bter took for me ~48 hours, so its ok.
I've written to support several times, the answer was "Sir, please wait"
Contacts with support is useless, unless you know chineese
Deposit to bter took for me ~48 hours, so its ok.
I've written to support several times, the answer was "Sir, please wait"
Contacts with support is useless, unless you know chineese
I tried to deposit some Nxt to BTER yesterday and it already had more than 20 confirmations after an hour, but didn't go through yet. I already contacted the support.
Does anybody else have this issue?
Does anybody else have this issue?
JeanLuc
You said you now use embedded jetty. My current setup is that i use embedded jetty and feed the Nxt servlet on startup to jetty.
What's the setup you use for jetty? Will i still need to embed my own or will 0.8.0 take care of that?
You said you now use embedded jetty. My current setup is that i use embedded jetty and feed the Nxt servlet on startup to jetty.
What's the setup you use for jetty? Will i still need to embed my own or will 0.8.0 take care of that?
Will the interfaces for the major components (Account, Transaction, Peer etc..) stay roughly the same?
Also the listener interfaces, will they remain?
Some of them. There are two big changes. First, Nxt is no longer a servlet and does not need to follow the servlet init/destroy lifecycle anymore. It is initialized reading its properties from nxt.properties instead of web.xml. If needed, it will start a PeerServlet that accepts peer-to-peer requests, an APIServlet that serves http/json API requests, and a UserServlet that supports the current NRS javascript client. You can disable all of those in the properties file, so if you are only using the Java API, and don't have a public IP on which to accept incoming peer requests, you will not be running any servlets at all.Also the listener interfaces, will they remain?
Second, I am making Block, Transaction, and Blockchain, interfaces. The current Blockchain class is a bunch of static methods, I am splitting those into BlockchainProcessor, TransactionProcessor, and Blockchain/BlockchainImpl classes. All those will be singletons instead of collections of static methods, which I believe is more flexible in the long term.
Peer has also been split into Peer (an interface), PeerImpl (package-local implementation), and Peers (static methods that handle the whole set of peers).
Account, Asset, Order, Alias, etc, will not change for now. In the future I will have to move them to the database, so I don't want to waste time refactoring them now only to change them again later.
I will try to keep the Listener interfaces, and see how I can use them to accommodate your request for monitoring the initialization steps too.
Finally some sanity on the codebase. The original code base you couldn't make head or tails as to which request handled the client and which one handled the protocol.
Finally removing all those static methods. Hopefully you remove all those static variables too!
Anyway, I've seen the 0.7 code and I have to say that you've made good progress from the original horrible code.
BTW, when will you folks release the source code?
Local Signing? Blockchain Pruning? Shrinking? Morphing? Timetravel?
Come-ooooooooooon tell us-from-beyond the horizon!
Modelling forging with leased forging power. Trying to find flaws.
Will the interfaces for the major components (Account, Transaction, Peer etc..) stay roughly the same?
Also the listener interfaces, will they remain?
Some of them. There are two big changes. First, Nxt is no longer a servlet and does not need to follow the servlet init/destroy lifecycle anymore. It is initialized reading its properties from nxt.properties instead of web.xml. If needed, it will start a PeerServlet that accepts peer-to-peer requests, an APIServlet that serves http/json API requests, and a UserServlet that supports the current NRS javascript client. You can disable all of those in the properties file, so if you are only using the Java API, and don't have a public IP on which to accept incoming peer requests, you will not be running any servlets at all.Also the listener interfaces, will they remain?
Second, I am making Block, Transaction, and Blockchain, interfaces. The current Blockchain class is a bunch of static methods, I am splitting those into BlockchainProcessor, TransactionProcessor, and Blockchain/BlockchainImpl classes. All those will be singletons instead of collections of static methods, which I believe is more flexible in the long term.
Peer has also been split into Peer (an interface), PeerImpl (package-local implementation), and Peers (static methods that handle the whole set of peers).
Account, Asset, Order, Alias, etc, will not change for now. In the future I will have to move them to the database, so I don't want to waste time refactoring them now only to change them again later.
I will try to keep the Listener interfaces, and see how I can use them to accommodate your request for monitoring the initialization steps too.
Sounds cool! When do you expect to release 0.8.0?
Also the setup where you split out the actual peer handling and the pure blockchain interface is perfect, it would allow for even better tools to analyze the blockchain.
Will the interfaces for the major components (Account, Transaction, Peer etc..) stay roughly the same?
Also the listener interfaces, will they remain?
Some of them. There are two big changes. First, Nxt is no longer a servlet and does not need to follow the servlet init/destroy lifecycle anymore. It is initialized reading its properties from nxt.properties instead of web.xml. If needed, it will start a PeerServlet that accepts peer-to-peer requests, an APIServlet that serves http/json API requests, and a UserServlet that supports the current NRS javascript client. You can disable all of those in the properties file, so if you are only using the Java API, and don't have a public IP on which to accept incoming peer requests, you will not be running any servlets at all.Also the listener interfaces, will they remain?
Second, I am making Block, Transaction, and Blockchain, interfaces. The current Blockchain class is a bunch of static methods, I am splitting those into BlockchainProcessor, TransactionProcessor, and Blockchain/BlockchainImpl classes. All those will be singletons instead of collections of static methods, which I believe is more flexible in the long term.
Peer has also been split into Peer (an interface), PeerImpl (package-local implementation), and Peers (static methods that handle the whole set of peers).
Account, Asset, Order, Alias, etc, will not change for now. In the future I will have to move them to the database, so I don't want to waste time refactoring them now only to change them again later.
I will try to keep the Listener interfaces, and see how I can use them to accommodate your request for monitoring the initialization steps too.
Local Signing? Blockchain Pruning? Shrinking? Morphing? Timetravel?
Come-ooooooooooon tell us-from-beyond the horizon!
Ideally there would be a listener you could register or some sort of progress monitor. In eclipse you have the IProgressMonitor interface, such an interface would be perfect, i included a simplified example.
public interface IProgressMonitor {
public void beginTask(String name, int totalWork);
public void done();
public void worked(int work);
}
The monitor would be provided by the user and is passed to the various startup methods. When reading the blockchain (for instance) you would call monitor.beginTask("Read blockchain", totalNumberOfBlocks) and then on each (or each 5th, 10th etc.) block read you call monitor.worked(numberOfBlocksRead). At the end you would call monitor.done().[/i]
A listener for log messages would be very nice to. I now remove the nxt.util.Logger class and replace with my own in order to display messages in the dialog that displays startup progress. Not a clean solution at all.
I will keep that in mind. I am making a lot of changes in 0.8.0. Will think about how to do it when I get to it.public interface IProgressMonitor {
public void beginTask(String name, int totalWork);
public void done();
public void worked(int work);
}
The monitor would be provided by the user and is passed to the various startup methods. When reading the blockchain (for instance) you would call monitor.beginTask("Read blockchain", totalNumberOfBlocks) and then on each (or each 5th, 10th etc.) block read you call monitor.worked(numberOfBlocksRead). At the end you would call monitor.done().[/i]
A listener for log messages would be very nice to. I now remove the nxt.util.Logger class and replace with my own in order to display messages in the dialog that displays startup progress. Not a clean solution at all.
Will the interfaces for the major components (Account, Transaction, Peer etc..) stay roughly the same?
Also the listener interfaces, will they remain?
The hacker conference HOPE X will be taking place at the Hotel Pennsylvania in NYC on July 18-20 of this year. There is currently a call for speakers:
http://www.2600.com/?q=content/announcing-hope-x-and-100-more-hours-hope-video-are-now-online
Quote
Call for Speakers
Attention all hackers, makers, whistleblowers, artists, phone phreaks, rebels, technologists, and free thinkers everywhere! Come and share your ideas, thoughts, and passions with thousands of really bright, creative, and open-minded people in New York City this summer at HOPE X.
We have room for around 100 talks and panels covering a wide range of topics, limited only by our collective imagination. Past talks and panels have included: anonymity, surveillance and countersurveillance, social engineering, hardware hacking, cryptography, privacy, security, censorship, programming, democracy and law, digital protests, society hacking, copyright, phone phreaking and telecommunications, new technologies, all manner of experimentation, and so much more. We are constantly searching for innovative subjects and presentation formats.
Attention all hackers, makers, whistleblowers, artists, phone phreaks, rebels, technologists, and free thinkers everywhere! Come and share your ideas, thoughts, and passions with thousands of really bright, creative, and open-minded people in New York City this summer at HOPE X.
We have room for around 100 talks and panels covering a wide range of topics, limited only by our collective imagination. Past talks and panels have included: anonymity, surveillance and countersurveillance, social engineering, hardware hacking, cryptography, privacy, security, censorship, programming, democracy and law, digital protests, society hacking, copyright, phone phreaking and telecommunications, new technologies, all manner of experimentation, and so much more. We are constantly searching for innovative subjects and presentation formats.
http://www.2600.com/?q=content/announcing-hope-x-and-100-more-hours-hope-video-are-now-online
Ideally there would be a listener you could register or some sort of progress monitor. In eclipse you have the IProgressMonitor interface, such an interface would be perfect, i included a simplified example.
public interface IProgressMonitor {
public void beginTask(String name, int totalWork);
public void done();
public void worked(int work);
}
The monitor would be provided by the user and is passed to the various startup methods. When reading the blockchain (for instance) you would call monitor.beginTask("Read blockchain", totalNumberOfBlocks) and then on each (or each 5th, 10th etc.) block read you call monitor.worked(numberOfBlocksRead). At the end you would call monitor.done().[/i]
A listener for log messages would be very nice to. I now remove the nxt.util.Logger class and replace with my own in order to display messages in the dialog that displays startup progress. Not a clean solution at all.
I will keep that in mind. I am making a lot of changes in 0.8.0. Will think about how to do it when I get to it.public interface IProgressMonitor {
public void beginTask(String name, int totalWork);
public void done();
public void worked(int work);
}
The monitor would be provided by the user and is passed to the various startup methods. When reading the blockchain (for instance) you would call monitor.beginTask("Read blockchain", totalNumberOfBlocks) and then on each (or each 5th, 10th etc.) block read you call monitor.worked(numberOfBlocksRead). At the end you would call monitor.done().[/i]
A listener for log messages would be very nice to. I now remove the nxt.util.Logger class and replace with my own in order to display messages in the dialog that displays startup progress. Not a clean solution at all.
´What's unethical about paying for services? If an exchange wants to list it and the payment amount is reasonable, why not?
Paying is OK, the bidder contest is wrong.
Anyway, we need 3000 votes asap. https://www.mintpal.com/voting
We will be back in first place shortly I hope.
2900
´What's unethical about paying for services? If an exchange wants to list it and the payment amount is reasonable, why not?
Paying is OK, the bidder contest is wrong.
Anyway, we need 3000 votes asap. https://www.mintpal.com/voting
We will be back in first place shortly I hope.
Maybe allocate some funds to Peer Explorer. The person running it just got NXT stolen out of caches meant for node administrators. The whole cache program he's running encourages the creation of VPS nodes. Just a suggestion.
+1000 Jump to: