[Sugar-devel] sugar-web - API for storing data

Manuel Quiñones manuq at laptop.org
Tue Sep 3 16:28:50 EDT 2013

Two more comments on localStorage.

1. First I found the "storage" signal that is supposed to be emitted
when localStorage changes.  And I said, great, let's take adventage of
it to save to the datastore.


But turned out it can't be used, because of

2. I tried to overload setter and getter methods of localStorage, but
there is no way to do that in JS (yet, search for dynamic proxies).
You can define a setter and getter for one property, but not for any.


Anyways, explicit is better than implicit, and is good to not mess
standard objects.

2013/9/3 Manuel Quiñones <manuq at laptop.org>:
> I'm back into this.  After discussing with Daniel some weeks ago, we
> agreed that the activity is the one who knows if it needs to store,
> not the toolkit.  So we prefer to let the activity developer do the
> storing, instead of doing when the activity goes to the background.
> Also the API I have proposed at that time was only for text data.
> Storing in web activities is a bit more complicated because there is
> no file descriptor to write to.  On the other hand, most webapps store
> text in JSON format
> So now I'm proposing a helper class called JSONStore that uses the
> standard localSorage.  I made it work in Get Things Done activity.  I
> will send a PR to add it to sugar-web.  Here it is:
> https://github.com/manuq/gtd-activity/blob/master/js/jsonstore.js
> An adventage of using localStorage is that it persists in a normal
> browser as well.  See http://manuq.github.io/gtd-activity/
> The usage is like this:
> myStore = jsonstore.JSONStore();
> myReadyCallback = function () {};
> window.addEventListener('storeReady', myReadyCallback);
> var value = myStore.read('key'); // read
> myStore.write('key', newValue); // write
> // Or use localStorage directly, and then call save():
> var value = localStorage['key'];
> localStorage['key'] = newValue;
> myStore.save();
> 2013/8/16 Daniel Narvaez <dwnarvaez at gmail.com>:
>> Hey,
>> It seems be have two (mostly) independent questions here
>> - How do we notify an activity of certain global events, being them
>> onPause/onStop or onRead/onWrite.
>> If we want them to be passed in activity.setup() I think we should use an
>> object, like {"onSomething": ..., "onSomethingElse":..}. That will allow to
>> subscribe only to some of the available events. With two events that would
>> probably be overkill but if nothing else I think onStart/onPause/onStop
>> should be supported, even if we also have onRead and onWrite. They are
>> needed for more than writing to the datastore.
>> Though, any reason to not use custom DOM events? This seems exactly the use
>> case they are designed for.
>> http://www.w3.org/TR/DOM-Level-3-Events/#extending_events-Custom_Events
>> - Should we have onRead and onWrite events.
>> What you are proposing is a bit different from what you have implemented. In
>> your patch onWrite does only a couple of things
>> 1 Proxy both onPause and onStop to the same write method.
>> 2 Close the activity in onStop.
>> I think 1 is not enough to justify onWrite existence, it's easy enough for
>> the concrete activity to do it if wanted.
>> About 2, I think the concrete activity needs more control on when it is shut
>> down. It might want to do so after having written some file outside the
>> journal, for example.
>> Now, you are proposing that we pass metadata in both read and write,
>> similarly to the gtk API. But what about the data? I don't see exactly where
>> you are going with this, so it would helpful if you could sketch out that
>> API.
>> That was a bit long, to summarize:
>> * I think onStart/onPause/onStop should be there in any case.
>> * On the top of those, your current onWrite implementation adds too little
>> to be justified.
>> * I tend to think we should use custom DOM events here instead of callbacks,
>> if possible.
>> On 16 August 2013 14:01, Manuel Quiñones <manuq at laptop.org> wrote:
>>> This is one of the most important APIs we will have, so I would
>>> like to open discussion on it.
>>> In GTK activities, the activity developer subclass Activity, and
>>> override read() and write() methods.
>>> In web activities, we don't have that kind of hierarchy.  Instead, the
>>> activity developer imports 'activity/activity' module, and calls
>>> activity.setup() .  Then she/he can use activity.getDatastoreObject()
>>> to read and write.
>>> In GTK activities, 'read' is called at startup and 'write' is called
>>> when the activity goes to the background or when it stops.  Recently,
>>> I added in sugar-web those notifications, with the intention to make
>>> web activities behave like GTK ones.
>>> I provided an initial patch and dnarvaez proposed another option:
>>> https://github.com/sugarlabs/sugar-web/pull/74
>>> So we can:
>>> - Let web developers connect to the 'pause' and 'stop' notifications,
>>>   and use the activity datastore object directly. Pro: is more
>>>   flexible.  Con: more work in the activity side: error handling,
>>>   datastore object handling.
>>> - Subscribe 'read' and 'write' functions in activity.setup() .  They
>>>   will be called as expected, like in GTK.  'read' will have a JSON
>>>   string as argument.  'write' must return a JSON string.  Pro:
>>>   simpler approach.  Con: less flexibility in the activity side.  A
>>>   mockup can be found in this comment:
>>> https://github.com/manuq/sugar-web/commit/3c2420f59c9aa8df44d2c0d639fe37b4af63f9fb#commitcomment-3872770
>>> Thoughts?  Any other ideas?
>>> --
>>> .. manuq ..
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>> --
>> Daniel Narvaez
> --
> .. manuq ..

.. manuq ..

More information about the Sugar-devel mailing list