search

digidem / mapeo-core

Library for creating custom geo data and syncronizing via a peer to peer network
23 stars 2 forks source link

Remove osm-p2p/kappa-osm and safe-fs-blob-store as required peer dependencies #46

Open okdistribute opened 5 years ago

okdistribute commented 5 years ago

The current constructor of mapeo-core requires users to pass in an instance of osm-p2p/kappa-osm, as well as something akin to safe-fs-blob-store.

This requires users to manage the versions of these peer dependencies. If one of them has a minor/patch version bump that isn't backwards compatible, it runs the risk of breaking upstream modules without warning.

If mapeo-core instead provides sane module defaults (perhaps along with pinned dependencies a la package-lock.json or otherwise), with the ability to override them, this is less likely to happen. Of course, there is still always the chance that someone will bump a dependency that isn't backwards compatible, but upstream consumers of mapeo-core can be more assured that mapeo-core is at least internally consistent with itself.

Another added benefit is that new adopters don't have to copy/paste the boilerplate of instantiating their own osm-p2p and safe-fs-blob-store instances to get started.

hackergrrl commented 5 years ago

What do you think about this being in mapeo-server instead? Having core be storage agnostic feels important to me, but it's the server module that all of the clients rely on. Maybe that'd be a good place for solidifying the storage deps?

okdistribute commented 5 years ago

@noffle I think I said this but I didn't make it clear, if this happened then it would be important to have the ability to override them, would that help that use case?

also yes definitely -- mapeo-server also requires the user to pass in osm/media deps which gets passed down, to core. Would be nice to have mapeo-server take a mapeo-core instance directly, I think.

luandro commented 3 years ago

The sub-tasks for solving this issue:

hackergrrl commented 3 years ago

Nice breakdown of tasks!

Should we have default core (kappa-core), index (level) and storage for kappa-osm?

Yes, I think that's a good idea. kappa-osm can bundle kappa-core, level, and random-access-file. If opts.storage or opts.index is a string, it can use level/raf, otherwise it should expect an instance of that storage mechanism.

Then users can create a kappa-osm /wo needing to worry about deps, then create a mapeo-core /wo worrying about deps, and then pass that instance right into mapeo-server.

How should the media and osm paths be passed?

We allow a string to be passed in for the osm param in mapeo-core and just create the kappa-osm instance for them /w relative paths for storage and index.

We could accept a string OR blob-store instance for media, and create a storage /w safe-fs-blob-store if it's a string.