[bisq-network/proposals] Bisq 2.0 - A multi-protocol DEX (working title Misq) (#330)

[chimp1984]

>     * **Ambitious**  I would want to work on Misq for the mid/long term, but wonder (like everyone else) if it is possible to build this and keep Bisq going with the current number of devs.  That said, I'm ready to dive in.
> 

Yes it should be done in parallel, so Bisq just continues as it is until the new project is mature enough to take over and even then the old Bisq could be kept running if there is demand.

>     * **Roadmap**  You suggest developing a parallel Lisq version separate from Bisq, then integrating Lisq into Misq.  I suggest new work begins on Misq, while calling it Lisq.  As soon as Misq can support Lisq and Bisq, re-name it Misq.  I assume there are components in Bisq that could be used by Lisq, and bits of Bisq integration into Misq can begin at once.
> 

Not so sure anymore if a renaming is a good idea, as it might confuse users and we managed to build up a very valueable brand. But maybe its good to have a working title to not confuse normal Bisq with the new one...

>     * **Modules**  I worked on an OSGi module based system when Java Modules were just a spec, and it was painful.  But I think building java apps from fine grained modules is a very good way to separate concerns, manage dependencies, and put together multiple apps from pre-defined module lists -- details non techie users do not need to be concerned about.  I assume Java Modules are easier to work with than OSGi of 15 years ago, and we could move Gradle's current responsibility for defining modules to Java Module definitions.  I'm not sure how Gradle works with Java Modules, but I also assume it would not be messier than the current build file.  [EDIT  I do not think the current build file is messy, but it will be if we start defining lots of new, small scoped sub projects.]

Yes I think those old OSGi like heavy weight frameworks have been a big failure.

I mean module just from a conceptual point of view. An entity doing one clearly scoped thing and not more. This can be a package in the code or a module as in Bisq the dif. modules or a library project or even written in another language and run as independent process and interact via TPC channels using ZeroMQ or the like.
I think we should start the most simple but take care to keep those boundaries clean. 

At the moment I try to focus on the high level picture and concept to not get lost in details, but there will be quite a lot to fine-tune about the architecture like choosing the message format, module APIs, etc....
Once we have a more clear plan I will continue on my P2P network prototype and we can build on top of that and finetune from there....

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/330#issuecomment-827121366
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210426/d44f1994/attachment.htm>