Protocol Engine Refactor #181
Sans évaluateur
Labels
Sans labels
applications
BLOCKED
bug
design
duplicate
enhancement
fixed?
funding-needed
help wanted
infrastructure
invalid
payments
qubes
question
ready-for-implementation
refactor
spam
tapir-server
testing
tor
wontfix
Sans jalon
4 participants
Notifications
Échéance
Aucune échéance n'a été définie.
Dépendances
Aucune dépendance définie.
Référence : cwtch.im/cwtch#181
Chargement…
Référencer dans un nouveau ticket
Sans contenu.
Supprimer la branche "protocolengine"
La suppression d’une branche est permanente. Bien qu’une branche supprimée puisse temporairement subsister, elle NE PEUT PAS être facilement restaurée. Continuer ?
Very large refactor:
A few things that are still weird:
Nevertheless, take a look as it likely impacts your integrations. Everything works as is, and the old CwtchPeer interface is mostly respected (I didn't have to change much of the cli at all - however, other integrations that rely on AIF behavior will be broken, as that is one more area that needs tidying)
Drone Build Status: success
https://build.openprivacy.ca/cwtch.im/cwtch/332
just taking an early look
any reason peer.Init doesnt take a manager and create an eventBut internally? just looking at the integ tests and you had to create a whole bunch of busses manually and pass them in then.
then you could also wire eventBus.Shutdown into peer.Shutdown
seems like a cleaner API
aaaah. so in the app code i see app just has one eventBus and shares it with all the peers. Do events properly indicate what peer they are about? because if so the integ tests only need 1 event bus to share with all 3 peers, and if not then I think multi user is broken in the app
Because the eventBus is/(will be eventually) shared between all components in the system and so it's lifecycle should not be managed by any particular subsystem.
because each peer in the integ case is representative of a seperate peer and so has a different bus. It's more accurate that these are tested with seperate event buses.
Yeah this is a good point, though multi-user isn't broken...it will still work, but there will be a lot of redundant work & errors that are not really errors (e.g. trying to listen to the same onion twice). Events could indicate intended subsystem/peer (or we could have different event registrations per peer)
I don't have a strong opinion either way, something we can dive into on Monday.
otherwise lgtm
lgtm!
Most recent change:
Drone Build Status: success
https://build.openprivacy.ca/cwtch.im/cwtch/334
Drone Build Status: success
https://build.openprivacy.ca/cwtch.im/cwtch/336