We included the ability to start and stop Jetty since we like the user to be able to delete the blockchain and start-fresh from a command in the UI
Re-init after shutdown will be tricky to support for me, because in many places I have init-once only singletons or static blocks, but for this use case I can probably provide a Nxt.fullReset() method that just deletes the genesis block from the database (and if I can trust the database triggers, this should wipe the rest of it too).
What can you say about the status of the database, will it remain H2 and will this remain an internal implementation or do you see developers accessing or updating data in the database them selves?
I am not changing anything about the database. Some people have asked me about using mixed-mode for it, where a tcp server is started automatically and external processes can connect to it. I don't want to enable this by default for security and performance reasons, but I will make the database jdbc url a parameter in the nxt.properties so that client developers can do such tricks in their customized distributions. It is not possible to restrict db access to read-only for such an external process, so if you abuse that and write to the db expect things to break.
Also, regarding custom colored coins. Will you be doing some more standardization in that area? Will there be more work towards an API to work with *custom* attachments? Not that it's strictly needed just wondering if you had ideas in that area.
Haven't thought about this at all yet. But yes, I realize that transaction attachment types don't need to be all hardcoded, one day you can have custom attachment types that just need to conform to some API, and not even need to be supported by all clients.
