deforking abstraction about osm-p2p-db HOT 2 OPEN

I agree. When I started on the problem, my thinking was "osm-p2p-db is a forking database, so it shouldn't need to worry itself with matters of creating an artificial, linear history" followed by "perfect! sounds like separation of concerns: streams are great for that". What I think I didn't take into account at the time was how interwoven the OSM part of osm-p2p-db and presentation of history really are. I believe that creating a linear history out of a non-linear history is an inherently opinionated process, but many of the dependency opinions are baked into osm-p2p-db already.

Going forward, I'm happy with trying your idea of offering up an opts.defork onto queryStream and get in osm-p2p-db. Thanks, Gregor!

from osm-p2p-db.

Work items

• Move osm-p2p-defork into an inner module within osm-p2p-db
• Expose opts.defork onto the queryStream and get APIs
• osm-p2p-db minor version bump
• Update osm-p2p-server to drop its own local defork logic and use the new API flag

from osm-p2p-db.