deforking abstraction

[gmaclennan]

I think osm-p2p-defork may be a level of abstraction too far. There are two ways of getting data out of osm-p2p-db that would need deforking: .queryStream() and .get(). I think it makes more sense to build in deforking to these methods, essentially merging the work done on osm-p2p-server into osm-p2p-db. Deforking is very tied to internal implementation details of osm-p2p-db, and I think having it as an external module could make it more difficult to maintain and for others to understand.

[hackergrrl]

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!

[hackergrrl]

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