Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Override default deserialization #5

Open
jarrvis opened this issue Nov 29, 2022 · 1 comment
Open

Override default deserialization #5

jarrvis opened this issue Nov 29, 2022 · 1 comment

Comments

@jarrvis
Copy link

jarrvis commented Nov 29, 2022

Is there a way to bypass deserialize call after getting data?
https://github.com/Level/browser-level/blob/main/index.js#L135

I need to work with js objects with no encoding. Details here:
https://gist.github.com/saulshanabrook/b74984677bccd08b028b30d9968623f5

I can disable encoding over level's public API but deserialization of browser-level still encodes objects as Uint8Array.

I understand that using level without encoding sounds weird as I may as well just use indexeddb directly if I don't need encodings. I use level to get a little nicer API and browser / nodejs / in memry abstraction.

@vweevers
Copy link
Member

vweevers commented Nov 29, 2022

We went down this road before, and it wasn't a success (Level/memdown#186 (comment)). It causes compatibility and extensibility issues, removes the ability to swap keys and values (e.g. for indexing use cases) because the key encoding (or lack thereof) wouldn't sort keys consistently, and generally increases code complexity.

At some point in the future I would like to revisit this, but in a different way. Ideally, rather than just using one of 3 predefined encodings (buffer, view or utf8) an abstract-level implementation like browser-level would be able to define its own encodings (like say, the JS structured clone algorithm). In addition, we need a better separation between key- and value encodings (e.g. so that we can throw if keys and values are swapped and use an incompatible encoding). But, we're talking far future. At the moment I'm focusing on features that improve modularity (like hooks) and that's much easier to do with predefined encodings.

If you can explain the use case in more detail, we can perhaps find an alternative solution (I might be reading that gist too quickly, but is it storing encryption keys alongside the ciphertext? How is that secure?)

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

No branches or pull requests

2 participants