Replies: 4 comments 3 replies
-
|
I spent a little time helping @sqrrm test his atomic-tx algo after he got past a fee service bug that was blocking him, but worked on the misq poc for most of the week. I created java SPI example that downloads bitcoinj.jar from jitpack, dynamically loads it classes, then syncs a regtest chain. It is not complex, but requires exact knowledge of all of bitcoinj's dependencies; they either have to be downloaded and dynamically loaded before bitcoinj.jar, or already be in the classloader before bitcoinj's classes are loaded. The design of any dynamically downloaded module (dep jars + impl jar + misq-spi jar) will require decisions about which transitive dependencies should be in the runtime at startup, or downloaded and dynamically downloaded. I studied RxJava concepts and examples at https://www.tutorialspoint.com/rxjava/index.htm. I needed to do this because the Ratpack api relies on it, and the ratpack api has confused me at times. However, RxJava looks like an elegant async model option in comparison to java Futures, which get messy when you nest them. I did not get as far as looking at @chimp1984's view module <--> presentation module binding examples. I spent time organizing the misq-poc-ii gradle project, containing the dynamic bitcoinj module loading example, a grpc server, a web server, and a javarx tutorial project. The java module JPMS api is ignored. It was decided JPMS would not work in a misq project containing many unmodularized dependendenies because that would prevent Misq from benefiting from JPMS' most important features (separate module classpaths with their own precisely defined dependency sets). I won't go into the details of the misq poc's gradle build and code organization here. I'll check it in later this week so you can look if interested. But since we've decided not to use JPMS, I think it's OK to start using the term "Module" interchangeably with "Gradle project", without any ambiguity with JPMS modules. I also built a crude, lightweight dependency-injection mechaninsm (Zuice), and am deliberately trying to prevent google guice from sneaking into the Misq dependency graph. I don't know if my solution will be able to replace guice, but it works if each module is responsible for wiring up its own api instance, and those instances are gathered in the application layer -- to be passed to server modules as needed.
CoreApi and WalletInstallerApi contain the public entry points to lower level services, like the current Bisq CoreApi exposes P2P, Wallet, etc., services to the GrpcServer. My next steps:
I may need to switch over to help out with atomic-tx if SQ asks. |
Beta Was this translation helpful? Give feedback.
-
Do you refer to the basic or the CompleteableFutures? The CompleteableFutures are pretty neat IMO. But RX is an interesting candidate as well. But we should stick to one approach and not mix both IMO but I think they cover different use cases.
I dropped that again as it did not fit well.
I am still not sure if we should use any at all. So far I avoided it and it did not cause real pain but in the opposite helped me to get design more appropriate and reduce dependencies. I fear with DI its just too easy to get dependeny in where there should not be any. |
Beta Was this translation helpful? Give feedback.
-
I was really referring to nested callbacks. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Yes with CompleteableFutures we want to avoid that.
I would not spend too much time on it. Maybe its still a bit early for Graal and we should not use our time as beta testers... |
Beta Was this translation helpful? Give feedback.
-
|
Weekly update (2 this week) here: |
Beta Was this translation helpful? Give feedback.
-
P2P network:
I made a break with P2P network work and started to work on the UI.
Reason is that I got motivated to do some visual work and as Neiman and one UX expert are working on the offerbook and create offer UX it will force me to think also more in details about those challenges.
Also it will make testing use cases for the P2P network a bit more realistic and helps to see if the interfaces work well with concrete client use cases.
Its all very preliminary and intention was to try out some more complex UI use cases to see if the design works.
I wanted to avoid that UI code can get mixed up with domain code and the only real protection is to have no domain dependencies in the
jfxmodule. On the other side the domain should not have any dependencies to the UI layer.To achieve that I made following structure:
The
jfxmodule has only javafx dependencies and other UI related ones, but no domain dependencies, not even common. So that way one cannot do anything more complex beside building the UI and binding it to primitive values like strings.The
presentationmodule has the OfferBook domain class. This listens on the networkService for offers and collects it in a list and notifies listeners. There is also a class for converting Offer domain data to display strings (OfferDisplay). This module has of course also no dependency tojfxor javafx packages.The
desktopmodule glues both together. It is the starting point for the application. It has some minimal javafx dependencies to allow usage of properties for the UI side as well as it needs to know the javafx Application class.So the realtions ships are:
View knows ViewModel
Presentation knows other domains like NetworkService
Application knows ViewModel and Presentation and serves for converting domain data to UI data and providing the services like a marketprice service. It does not do any formatting, etc. as we want to re-use such code for other frontends this all is in presentation.
One tricky thing was how to support dynamic data in itemrenderers like price and amount update for market based priced offers. In Bisq we have the pricefeedservice inside offer (which was never a good idea...). We also do not handle that non-visible items are not updated unneccessarily which causes performance costs.
I implemented it now that the ListItem has only the data it needs to display and no logic beside adding and removing listeners when an item gets visible or invisible. The calculation is done by a supplier function which we get provided as constructor parameter. The marketprice updates are handled via a property on the market value. This shared property is set in the application layer. I tested it with 200k offers and 100 ms market price updates as well as constantly added and removed offers and scolling though the list was super fluent. In contrast when i deactivated the handling for not updating invisible items performance got quickly pretty bad.
To be sure that this concept works I will continue on the create offer view as that is the most complex one.
Here is a screenshot of current state...
Beta Was this translation helpful? Give feedback.
All reactions