You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have prepared the structure for the application startup.
For parsing the program arguments and reading in property files we need to implement an option parser.
Here is my suggested design for that:
Each domain will have its own option parser and stores it in the domain specific option which gets passed as parameter to the contstructor for the domain class (next to optional dependencies to other domain classes).
That way we avoid that we get a huge options class where all domains gets mixed up as well as a long parameter list for the domain classes.
Here are the domain and api classes: https://github.com/chimp1984/misq/tree/chimp_prototype/api/src/main/java/network/misq/api
The Domain class (might get renamed to some better term) is creating the domain objects and use the specific option parsers to provide the options for each domain. Further it has the initialize method which gets called from the application after the basics are setup (e.g. javafx has launched).
When we use propery files we should use some name space convention for the mapping to the domains. Same might be useful for program arguments, though not sure how well that works if we want to stick to common styles.
At the moment there is not much concrete content for those options but the long list of arguments in Bisq can serve as idea what might get added over time to Misq.
Any developer interested to work on that? If so please assign yourself and/or leave a comment.
The text was updated successfully, but these errors were encountered:
And refactor TorIntegrationTest into AsyncBootstrapTest #2.
Note: Adding Tor bootstrapping tests add time to build.
To skip tests, run `$./gradlew clean build -x test`.
I have prepared the structure for the application startup.
For parsing the program arguments and reading in property files we need to implement an option parser.
Here is my suggested design for that:
Each domain will have its own option parser and stores it in the domain specific option which gets passed as parameter to the contstructor for the domain class (next to optional dependencies to other domain classes).
That way we avoid that we get a huge options class where all domains gets mixed up as well as a long parameter list for the domain classes.
Here is the application class:
https://github.com/chimp1984/misq/tree/chimp_prototype/application/src/main/java/network/misq/application
Its purpose is to provide generic application specific features. It does not know about the concrete domains.
Here are the domain and api classes:
https://github.com/chimp1984/misq/tree/chimp_prototype/api/src/main/java/network/misq/api
The Domain class (might get renamed to some better term) is creating the domain objects and use the specific option parsers to provide the options for each domain. Further it has the initialize method which gets called from the application after the basics are setup (e.g. javafx has launched).
Here is the javaFx application which defines which domain and api class to use. Beside the fully featured default version there can be partial domain/api classes for nodes which do not require all features like a pure network node (seednode).
https://github.com/chimp1984/misq/blob/chimp_prototype/desktop/src/main/java/network/misq/desktop/DesktopApplication.java
The option parsing framework could be taken over from the current Bisq application. But that is up to the dev working on that issue. Goal is to keep all as lightweight as possible.
Here are the relevant classes/packages:
https://github.com/bisq-network/bisq/blob/master/core/src/main/java/bisq/core/app/BisqExecutable.java
https://github.com/bisq-network/bisq/tree/master/common/src/main/java/bisq/common/config
When we use propery files we should use some name space convention for the mapping to the domains. Same might be useful for program arguments, though not sure how well that works if we want to stick to common styles.
At the moment there is not much concrete content for those options but the long list of arguments in Bisq can serve as idea what might get added over time to Misq.
Any developer interested to work on that? If so please assign yourself and/or leave a comment.
The text was updated successfully, but these errors were encountered: