Open devth opened 5 years ago
From @jcorrado via Slack:
I'm still of the "all of nothing, do it cleanly or don't do it at all" mindset (edited) but, I understand practical middle-ground (in theory) for me the simple thought experiment goes: were we to simplify to one adapter, what would that simplified, clarified architecture open up? and is that worth more than the what would be lost
were we to simplify to one adapter, what would that simplified, clarified architecture open up?
Corollary: What if we just design everything as if there were only one adapter (while still capturing provenance)? Rationale:
This is essentially what I've been doing all along and it hasn't hindered me. The remaining TODOs for Users would still be:
I think of it as a stepping stone to the ideal "all or nothing" state.
This means both sets of users show up in karma. Observers, Status, and Aliases are global. I think all of these are fine. I've always tried to let concrete use cases drive the design of Yetibot, and I don't think I have a strong enough multi adapter case (Yetibot public runs on Slack and IRC but no one uses it on IRC currently) to help drive its design while at the same time having a practical need for multi adapter.
In the future if/when YB supports Gitter or other platforms it will likely listen on all, and I think we want most state to be global in that case. Same with Clojure community chats: if/when we get Yetibot into Clojurians, #clojure IRC, clojure/general on Gitter, etc. When that happens I think I'll either have motivation to go all in or the clarity and confidence to make the call go single adapter.
Actively mulling this over...
tldr: agree with all or nothing but want to defer the decision / work.
We discussed this today starting at https://yetibot.slack.com/archives/C66AJ2EFL/p1554821184926700
identities
table that joins 1 or more rows from users
)In terms of simplifying adapters, maybe the adapter just needs to provide a function from uid to fully resolved user.
Opening this up as a place to discuss how we want to model users.
Goals of this discussion
Multi adapter
DB entities to consider:
Two extremes:
Current state
Currently Yetibot supports multiple adapters but it's somewhere between the two extremes.
Considerations
Current use cases of multiple adapters
Concluding thoughts
~devth
and my Slack ID is@U123123
- maybe this is akin to connecting an identity on a website to disparate oauth identity providers like twitter, fb, github, etc)username
is identical, thereby avoiding the problem with single-org multi-workspace users having different ids in each workspace. This could even be configurable (:attempt-to-stitch? true
).