<div dir="ltr">Great stuff! I'm a bit undecided about the API... I'll try to let it go through my head a bit more, until you post a pull request :) </div><div class="gmail_extra"> <div class="gmail_quote"> On 3 September 2013 16:52, Manuel Quiñones <<a href="mailto:manuq@laptop.org" target="_blank">manuq@laptop.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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: <a href="https://github.com/manuq/gtd-activity/blob/master/js/jsonstore.js" target="_blank">https://github.com/manuq/gtd-activity/blob/master/js/jsonstore.js</a> An adventage of using localStorage is that it persists in a normal browser as well. See <a href="http://manuq.github.io/gtd-activity/" target="_blank">http://manuq.github.io/gtd-activity/</a> 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 <<a href="mailto:dwnarvaez@gmail.com">dwnarvaez@gmail.com</a>>: <div class="HOEnZb"><div class="h5">> 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. > <a href="http://www.w3.org/TR/DOM-Level-3-Events/#extending_events-Custom_Events" target="_blank">http://www.w3.org/TR/DOM-Level-3-Events/#extending_events-Custom_Events</a> > > - 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 <<a href="mailto:manuq@laptop.org">manuq@laptop.org</a>> 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: >> <a href="https://github.com/sugarlabs/sugar-web/pull/74" target="_blank">https://github.com/sugarlabs/sugar-web/pull/74</a> >> >> 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: >> >> <a href="https://github.com/manuq/sugar-web/commit/3c2420f59c9aa8df44d2c0d639fe37b4af63f9fb#commitcomment-3872770" target="_blank">https://github.com/manuq/sugar-web/commit/3c2420f59c9aa8df44d2c0d639fe37b4af63f9fb#commitcomment-3872770</a> >> >> Thoughts? Any other ideas? >> >> >> -- >> .. manuq .. >> >> _______________________________________________ >> Sugar-devel mailing list >> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> >> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> > > > > > -- > Daniel Narvaez </div></div>-- .. manuq .. </blockquote></div> -- Daniel Narvaez </div>