Re: IndexedDB, what were the issues? How do we stop it from happening again?

2013/2/15 Shwetank Dixit <shwetankd@opera.com>

> Why did you feel it was necessary to write a layer on top of IndexedDB?
>>
>
> I think this is the main issue here.
>
> As it stands, IDB is great in terms of features and power it offers, but
> the feedback I recieved from other devs was that writing raw IndexedDB
> requires an uncomfortable amount of verbosity even for some simple tasks
> (This can be disputed, but that is the views I got from some of the
> developers I interacted with). Adding that much amount of code (once again,
> im talking of raw IndexedDB) makes it less readable and understandable. For
> beginners, this all seemed very intimidating, and for some people more
> experienced, it was a bit frustrating.
>
>
After my experiments with IDB, I don't feel that it is particularly
verbose. I have to admit that often I prefer slightly verbose syntax over
shorter one when it makes reading the code easier. In IDB's case, I think
this is the case.



>  For the latter bit, I reckon it would be a good practice for groups
>> working on low-level APIs to more or less systematically produce a library
>> that operates at a higher level. This would not only help developers in
>> that they could pick that up instead of the lower-level stuff, but more
>> importantly (at least in terms of goals) it would serve to validate that
>> the lower-level design is indeed appropriate for librarification.
>>
>
> I think that would be a good idea. Also, people making those low level
> APIs should still keep in mind that the resulting code should not be too
> verbose or complex. Librarification should be an advantage, but not a de
> facto requirement for developers when it comes to such APIs. It should
> still be feasable for them to write code in the raw low level API without
> writing uncomfortably verbose or complex code for simple tasks. Spec
> designers of low level APIs should not take this as a license to make
> things so complex that only they and a few others understand it, and then
> hope that some others will go ahead and make it simple for the 'common
> folk' through an abstraction library.


I quite don't see how to simplify IDB syntax much more. I think its request
object based API is very nice and transactions are much appreciated.
Possible simplification could be achieved by introducing somekind of auto
transaction mechanism so that user could get and change objects without
creating transactions. There are some challenges to enable this and it
would complicate the engine especially if transactions are still supported
when users want to use those. And I hope transactions are not dropped
completely. When using CouchDB, I often find my self writing some fairly
painful code to handle the lack of transactions.

Since IDB is aiming for its first standardised version of the API, I
wouldn't be too worried about people writing Javascript libraries that
simplify its use. As long as all low level capabilities are in place for
writing these abstractions, we should be in good order for the first
version of the standard. Later in following versions of the API we have
more experience about painful parts of IDB API and we can improve it and
simplify its use. Extending API by creating additional abstractions to
simplify its use is often more easier than going to other direction at
least according to my experience.

-- 
Miko Nieminen
miko.nieminen@iki.fi
miko.nieminen@gmail.com