I am implementing payment_streams_module as part of the LEZ payment-streams integration (logos-co/lez-payment-streams). My module sits between delivery_module (Universal) and lez_wallet_module (Legacy).
Because my upstream is Universal and my downstream is Legacy, I am forced to bridge the two patterns. I would prefer to build my new module on the Universal pattern to match the core team's strategic direction. However, because lez_wallet_module is still Legacy, I cannot declare it in my metadata.json to get the safe, static C++ wrapper (modules().lez_wallet_module). The logos-cpp-generator assumes all dependencies are Universal.
To help me decide whether to build my module on the deprecated Legacy pattern (to safely talk to the wallet via invokeRemoteMethod) or the new Universal pattern (which forces an untested dynamic call to the wallet), I wanted to ask:
Is there a planned roadmap/timeline for migrating logos-execution-zone-module to the Universal pattern ("interface": "universal", LogosModuleContext, etc.)?
Related: logos-co/logos-liblogos#135
I am implementing
payment_streams_moduleas part of the LEZ payment-streams integration (logos-co/lez-payment-streams). My module sits betweendelivery_module(Universal) andlez_wallet_module(Legacy).Because my upstream is Universal and my downstream is Legacy, I am forced to bridge the two patterns. I would prefer to build my new module on the Universal pattern to match the core team's strategic direction. However, because lez_wallet_module is still Legacy, I cannot declare it in my metadata.json to get the safe, static C++ wrapper (modules().lez_wallet_module). The logos-cpp-generator assumes all dependencies are Universal.
To help me decide whether to build my module on the deprecated Legacy pattern (to safely talk to the wallet via invokeRemoteMethod) or the new Universal pattern (which forces an untested dynamic call to the wallet), I wanted to ask:
Is there a planned roadmap/timeline for migrating logos-execution-zone-module to the Universal pattern ("interface": "universal", LogosModuleContext, etc.)?
Related: logos-co/logos-liblogos#135