You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After I've started working on #102, I can see that our architecture around the Telegram message processing is a bit messy, and it doesn't allow us to implement that feature in the right way.
Right now, Telegram message processing is done in multiple stages. Essentially, Emulsion.Telegram.Funogram module performs several synchronous transformations, and then passes a half-baked message (aka TelegramMessage) to the Core actor.
The Core, in turn, adds its own stage (Funogram.MessageConverter.flatten) for whatever reason, and then passes the resulting message to the XMPP message system.
The new processing we are about to add in #102 is asynchronous (because it will go to the database which involves I/O), and currently there's no good place to add it: everything in the pipeline is synchronous.
I suggest we do the following:
Make the processing stages more explicit (even if there're only two of them) – could help with testing.
Move the processing from the Core actor to the Emulsion.Telegram.Funogram (so it's not the Core responsibility, and Core is, once again, just a simple message bus).
Allow asynchronous stages in the Funogram pipeline.
Funogram itself requires the message handler to be synchronous, but that shouldn't be a problem for us: we do want to block Funogram from receiving the next message until we're finished with the current one (to avoid races).
The text was updated successfully, but these errors were encountered:
After I've started working on #102, I can see that our architecture around the Telegram message processing is a bit messy, and it doesn't allow us to implement that feature in the right way.
Right now, Telegram message processing is done in multiple stages. Essentially,
Emulsion.Telegram.Funogram
module performs several synchronous transformations, and then passes a half-baked message (akaTelegramMessage
) to theCore
actor.The
Core
, in turn, adds its own stage (Funogram.MessageConverter.flatten
) for whatever reason, and then passes the resulting message to the XMPP message system.The new processing we are about to add in #102 is asynchronous (because it will go to the database which involves I/O), and currently there's no good place to add it: everything in the pipeline is synchronous.
I suggest we do the following:
Make the processing stages more explicit (even if there're only two of them) – could help with testing.
Move the processing from the
Core
actor to theEmulsion.Telegram.Funogram
(so it's not theCore
responsibility, andCore
is, once again, just a simple message bus).Allow asynchronous stages in the Funogram pipeline.
Funogram itself requires the message handler to be synchronous, but that shouldn't be a problem for us: we do want to block Funogram from receiving the next message until we're finished with the current one (to avoid races).
The text was updated successfully, but these errors were encountered: