Release version 1 means that the API, as it states (or intention) is stable and ready for production use. Bug will be fixed without breaking the API for at least two years, probably a lot longer. Some modules development will be continued and will still be enhanced the API without breaking.
I have been developing and using javascript database library (YDN-DB) for nearly three years and now it is time to release. This is the time with multiple reasons.
First of all, I like the
API a lot. There are few I want to change,
but I cannot figure out significantly better alternative. As you can see,
API is very simple. Just instantiate the main class (ydn.db.Storage)
and start using right aways. It works on all browsers and mobile clients.
API is very concise, meaning you don't need to learn much, but use right aways. Expected
methods like add, get, put and clear
are there and works as expected.
At the same time, the API is very flexible and powerfull enough on very complex situation requiring transactions and multiple nested queries. I have being using the library to many large scale projects. Many other people are also using my library for large scale projects.
Performance is considered from the ground up as well as every piece of implementation. There is no caching to make it run faster. High performance is archived by using parallelization of database executions and using raw browser API as much as possible.
I apologize that my library is not working perfectly on some browsers like IE and on mobiles. The library works well on Chrome and Firefox. The main reason is that other browsers do not yet follow IndexedDB API specification. They can be polyfilled, but does so require a lot of testing and implementation. These missing API are for advanced use cases (multiEntry, compound index), but they are not easy to implement. So I will just wait, rather than trying to polyfill them.
Event module is incomplete. Implementing event is hard and also there is performance penalty. The use case are often, more of convenient than essential. IndexedDB API v2 is likely to have native support for Event. So, event module implementation need to wait and I may not fix bugs on this module.
Version 2 API focus on robustness, trading over ease of use. It is not
backward compatible. Only IndexedDB will be supported and use native
object like Promise,
IDKeyRange and
IDBCussor.
It will be less reliance on closure library or
possibly not using it at all.
I have proposed few API methods to W3 web app working group on IndexedDB API v2 specification. Most of these API methods are required for efficient key joining and query optimizations. The proposed methods are very likely to appear on v2. Of course, YDN-DB will be the first to support them and will be back port to v1 as well.
Main concept like schema, transaction thread and iterator style query will be carried forward. Most of the implementation will be focused on SQL execution. Synchronization with backend services and full text search will work out of the box.
Another main reason is, W3 web app working group has published release candidate for IndexedDB API v1 several months ago with consensus agreement with browser vendor except Apple. So I hope all browsers will implement IndexedDB API with strict compatibility.
Last reason is that today is my last day of work at National University of Singapore.