Shape of the API

[agorrod]

I'm at a bit of a decision point about the shape of the public API for this Node interface.

There are two directions to go in:

1) Implement an API that is compatible with Node LevelDown API. That will allow us to use the existing Node LevelUP package as a higher level interface.

2) Implement an API that more closely follows the existing WiredTiger interface, and exposes a greater proportion of WiredTiger functionality.

[agorrod]

The Node LeveDown interface limits WiredTiger by:

• LevelDB has only a single table - each WiredTiger table would exist in a separate database (with corresponding service threads).
• LevelDB has a different transactional model. In LevelDB there are batches, in WiredTiger we have a richer transactional model.
• LevelDB supports less concurrency than WiredTiger - it's possible that the LevelUP interface will limit how we expose that in WiredTiger.

Advantages of implementing LevelDOWN interface:

• Keeps our API simple.
• Allows us to be a replacement for existing LevelUP applications.
• Saves us needing to design/implement/maintain a Node API.

[agorrod]

We may also have another path into the LevelDOWN/LevelUP API combination - which would be to utilize the (new) WiredTiger LevelDB API.

[michaelcahill]

@agorrod, maybe we should spend a few hours working together to try to get the LevelDB API working with LevelDOWN? If that isn't too hard (or we can make it easy), then I agree it may not be a good idea to constrain our NodeJS interface.

[agorrod]

Works for me - I'm available this week. From what I can tell there are likely to be two complications:

• Integrating the WiredTiger build into a Node package. We should be able to copy-paste what I've done in the other Node interface.
• Non standard LevelUP backends (i.e: all other than LevelDOWN) implement an API called abstract-LevelDOWN, wheras the default doesn't appear to implement that interface. So creating a package will not be as simple as duplicating the content of the LevelDOWN implementation.