Skip to content
This repository has been archived by the owner on Dec 2, 2024. It is now read-only.

Where do we stand? #60

Closed
ralphtheninja opened this issue Feb 13, 2018 · 7 comments
Closed

Where do we stand? #60

ralphtheninja opened this issue Feb 13, 2018 · 7 comments
Labels
discussion Discussion
Milestone

Comments

@ralphtheninja
Copy link
Member

ralphtheninja commented Feb 13, 2018

I feel it's time to start focusing on this repository now. I'd really like to get this done and then ship level as one package to rule them all 😄

But first, lets breath some air into it.

However, I'm unsure of where we stand, like what should be done to make this work well.

Some links:

Lets use this issue to summarize what's needed and which direction we want to take it.

@vweevers @timkuijsten I feel you guys have have been digging around the most in this code and most likely have the most valuable input.

Some questions:

  • what is the big problem with the current implementation?
  • what are we fixing, except for using latest abstract-leveldown?
@ralphtheninja ralphtheninja added the discussion Discussion label Feb 13, 2018
@ralphtheninja
Copy link
Member Author

I'd like to use this issue to break down what needs to be done into concrete issues and add them to the v3 Milestone. Then we can prioritize easier and push it through. I'd be happy to help.

@vweevers
Copy link
Member

Because I'm short on time, some quick thoughts:

  • I think we should use level.js as the starting point (not the fork), to get clean PRs
  • level.js has custom logic for serializing buffers, typed arrays etc. Similar to what we did in memdown, we should strip most of the logic, prefer Buffer over typed arrays, and use _serialize* as the only code path for serialization.
  • Before (or in parallel to) the work here we should try and remove process.browser and similar hacks from abstract-leveldown
  • Iterators should by default keep reading from the underlying IDB cursor, to fulfill the snapshot guarantee
  • Removing idbwrapper is not a must for abstract-leveldown compliance (I think) but idbwrapper has terrible performance so if we can do it, great.

Also maybe I should plan a "levelvacation" 🙂 (meaning a vacation to work on level)

@vweevers
Copy link
Member

If we do remove idbwrapper, our first focus should be to clean our code up, making it work in latest Chrome, maybe do a prerelease or two, and only then worry about other browsers and any hacks we may need.

@ralphtheninja
Copy link
Member Author

Also maybe I should plan a "levelvacation" slightly_smiling_face (meaning a vacation to work on level)

💯

@timkuijsten
Copy link

@vweevers @timkuijsten I feel you guys have have been digging around the most in this code and most likely have the most valuable input.

At the time I was working on some sort of PouchDB alternative. The motivation to start hacking on level was because the software was a bit unmaintained and could use some love. Hence removing the wrapper, removing unneeded dependencies and updating required dependencies.

I haven't been closely involved with Node for a while and since I'm trying to move more into system programming I don't think that will change anytime soon. Feel free to use any of my code if it still makes sense ;) it's all released under ISC. Gl guys!

@vweevers vweevers added this to the v3 milestone May 24, 2018
@ralphtheninja
Copy link
Member Author

@vweevers This can probably be closed?

@vweevers
Copy link
Member

Yes! :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
discussion Discussion
Projects
None yet
Development

No branches or pull requests

3 participants