asarazan / bismarck Goto Github PK

I think there's probably a lot of cruft from the legacy stately model we copied. Would be cool to get things running on newer standards + kotlin build files.

So was thinking if we can call Bismarck.insert(Data), for whenever we might need to manually update Bismarck data, it might also be necessary to manually insert an error response.

For example, if the Fetcher just makes a get request, but later we need to make a put or a post, we would need to do that manually. If that network request has an error, shouldn't we also send that through to the eachError callback?

Need a common, file-based storage strategy for persisting to disk. Most of this is ready to go.

TODO:

• Finalize common FileLike interface
• Decide on what serialization should be supported out of the box (lean toward just kotlinx)
• Decide whether this file util should be its own lib

Need a way for a bismarck to "depend" on another bismarck, such that changes cascade down the dependency graph.

Should be pretty straightforward. It's probably just a clever use of eachValue

Do we want a transform "pipeline" such that we can essentially map the values coming out of a bismarck? Theoretically you could rig this up pretty easily on top of the existing eachValue flow. See RescopedBismarck for inspiration.

I didn't like the class hierarchy that we had, so I switched it to dedupe outgoing calls by default. I don't see a lot of utility in the dumb approach but I'm open to arguments

We need a relatively realistic reference Implementation, not only for our eventual consumers but for our own ideation.

Because eachError is backed by a ConflatedBroadcastChannel, it'll replay errors, but I might not be concerned with any previous error values. It would be nice if we could either clear the error, or have this work like a flow and "drop" the first error. Also, this seems related to issue #13, and could be solved by adding the ability to manually update the error value