search

digidem / osm-p2p-db

Peer-to-peer database for OpenStreetMap data
BSD 2-Clause "Simplified" License
235 stars 25 forks source link

deforking abstraction #52

Open gmaclennan opened 7 years ago

gmaclennan commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Work items