Idea: make async easier with "Then" event

This proposed schema looks like many of the modern key-value storage schemas, which don't truly commit the data to disk until some time later, hence the term "eventually consistent".

These systems generally last the lifetime of the system and have a special opportunity to write data on system shutdown, meaning data is only at risk in the event of a system crash or power loss. Browser tabs can be closed at any instant without warning, and there's no guarantee anything async you start when closing a tab will actually be completed (since the browser is probably going to cancel everything the tab was doing). This makes it difficult to build an eventually-consistent system, since you either have to go back to really writing data every time you set something, or keep writing data on an arbitrary time interval and risk losing data since the last interval. Random data loss is not acceptable for a storage plugin.

So I don't think this kind of thing belongs in the plugin itself - but you can make such systems if you wish by saving/loading entire Dictionary objects (or other kinds of data stores) to a single Local Storage key.

Delete.

I had no question. Thanks.

Delete

Thanks for suggestion, I had made my first version of dictionary cache plugin.

After loading cache completed, all read/write operations look likes synchronous.

- Read had been done while cache loaded.

- Writing actions in a tick would be fired at the same time ( in tick2() ). "Condition:On writing actions complete" will be triggered when all writing actions are done. User might wait this event or not.

Data in local storage are-

Sample capx , plugin.

Edit

The reading and writing actions of local storage are embedded inside this plugin. So it does not need to work with official localstorage plugin.

hi

can i use yout plugin with new local storage ?

and what are the benefits of your plugin please ?

thanks

matrixreal

You might try this solution first.

matrixreal

You might try this solution first.

sorry but still not understandnew plugin local storage and your plugin too

I thought a bit more and ended up at the conclusion that instead of creating a new generic 'Then' or 'Next' system condition (that doesn't mean much), it would be clearer if it was a special condition from the LocalStorage object, or the Pathfinding behavior kept it's 'On path found' condition and so on. 'On path found' describes a lot better what it does than a generic word like 'Next'. The same for something like 'On requested data ready' for the LocalStorage, it's a lot more meaningful.

My proposal is to create a new type of event, a kind of "scoped trigger" (in the sense of a trigger which acts depending on scope). It would have a different icon (like the different arrows for regular trigger and loop conditions) to differentiate it from the rest.

When placed below an event, it should automatically recognize the scope and act only in the scope of the previous event. In the case of the LocalStorage it could be an "On all completed" trigger for the previous 'request data' actions from the event above. For the Pathfinding behavior it could act as a regular trigger, but only fire for the previous 'Find Path' action from the event above. This allows to make contained triggers.

Exploring the possibilities, this "scoped trigger" could act locally only when placed as a sub-event, triggering only from the actions in the scope of it's parent event. This opens some new possibilities: when placed as a top-level-event it could be triggered by any related event, responding to any call throughout the event sheet. So it could be more versatile acting both as a local trigger (as a sub-event) or global (as a top-level-event) depending on scope. This new type of trigger would even allow local functions, that could be really handy.

Now focusing on the LocalStorage, I believe it would be possible to give options to use it both synchronously or asynchronously. For really small data like simple variables (probably the most common use), a synchronous storage works very well with a small performance impact, but compensates greatly with it's easiness of use. For big data like long strings, an asynchronous storage is better because it doesn't stall the whole event chain while reading or writing, but it complicates a lot the use of events.

So why not keep both and let the user choose depending on the circumstance or data type?

The LocalStorage could have a traditional set action with a get expression that works synchronously for small data, stalling the event execution until it's complete but requiring less events (like WebStorage did). And also asynchronous events like a 'Request data' action and a 'On requested data ready' "scoped trigger" for when big data is necessary. This would make it possible to use both simultaneously, getting the benefit of both systems depending on the data you are dealing with. Like using synchronous events for simple values like lives and scores, and using asynchronous events for long data like dialogs or level data for custom level editors.

*I'm assuming that in theory asynchronous events take the same amount of time to complete than synchronous, so it's possible to make synchronous events out of an underlying asynchronous system. If not then the change to an asynchronous system sounds much worst than I thought.

Ashley , I think a then event would be awesome . Would it work something like this?

Would we also be able to reject the promise at the 'then' events to limit execution.