[dojo-contributors] Dojo 1.9 Proposal

Sasha Firsov suns at firsov.net
Tue Oct 16 13:52:47 EDT 2012

On 2012/10/16 9:39 AM, Tom Trenka wrote:
> if we're thinking of this as an offline thing it'd probably be much 
> better to wrap the IndexedDB than LocalStorage, at least based on my 
> experience (which admittedly is about 2 1/2 years old now and in the 
> context of Adobe AIR).  I remember running into the same problems Ken 
> and Colin have alluded to; LocalStorage tends to be very slow, 
> especially with larger data chunks...and IIRC there's a limit as to 
> how much can be stored in it.  And given that most people are using 
> DTK to build single-page applications, that might end up being a bad 
> thing.
Some extremal thoughts FYI. Assuming "best" rather than "good" (which 
are enemies to each other).

There are a fast and ideal solutions. While shortcuts like squeezing 
developer into limited implementation/API will work, generic will be 
more beneficial.
The MemoryStore/Cache meant to be the fastest but it lacks of 
persistence, remote cloud (whatever API) will give unlimited space but 
awful performance. There are some intermediate compromises like IndexedDB.
Now try to make analogy with computer storage: memory 
cache-SSD-HDD-Network-Cloud. This chain finally is completed for file 
The dojo.store stack could support data distribution over chain and 
control the balance of data ownership. As we treat all data manipulation 
methods asynchronous the high-availability "tiers" will take the burden 
of timely response and heavy-lift ones on volume.
There are some additional patterns need to be introduced to support such 
data use.
- data commit could be multi-step process. The 1st tier in data delivery 
chain do not guarantee the final delivery.
- data are hanging in the middle in "dirty" state until propagated to 
the end of chain. Which will require some kind of "flush()" method to 
make a final commit.
- transactional API to support multiple changes with single push. 
Possibility to be rejected on one of following tiers and re-try by previous.
- observer for particular request and data set. Including notifications 
propagation across chain. Special challenge is preserving the request 
over the chain.
- you name it

It looks too heavy but I personally(as many of us) been faced such 
challenges and gladly will use such storage stack if exist. Since the 
task is too generic you will see multiple "good enough" for exact 
applications solutions but none of it will be generic enough to be worth 
promoting as DTK *storage stack*.

Once the stack requirements are settled, than it has a reason going to 
details what kind of tiers need to be implemented and priorities among 
them. It is early to talk about API and implementations without context 
where they will be used.

The "toolkit" approach goes against "storage stack" as it presents 
higher level of abstraction (please state ahead if we dismiss such).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121016/b6ba7f06/attachment-0001.htm 

More information about the dojo-contributors mailing list