Closed adambabik closed 5 years ago
@adambabik So the problem is also the other messages we send around for data sync, like OFFER
, REQUEST
and ACK
s. Would that work with this?
@decanus yes, it's up to you what to do with a message. However, in this particular change, I need to add message skipping. OFFER
and others would be decoded and handled by your decoder but not necessarily result in a valid protocol.Message
.
I will add this in a moment.
I am closing this because we need more refactoring:
protocol
package and return protocol.Message
. That's too specific. We should rename adapters
package to transports
and they should not import protocol
package at all to support any protocol.Messenger
should accept a protocol object or protocol adapter object that would translate raw values incoming from transports into protocol-specific objects.
@decanus would this change help with removing custom transport for data sync? I imagine it would work like this:
mvds.MessageHandler
would need to have a signature like this:func(data []byte) (protocol.Message, error)
and I imagine that it would first decode bytes to whatever you use to serialize data, extract metadata needed for data sync logic and returnprotocol.Message
.