You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Much of exhibit has been modified to manage scheduling using event triggering and listening. The database layer stands out in that it is still using continuations. More consistency would hold if the db layer were also modified to listen for and trigger events. Looking to the current event model, the obvious events would be
loadData.exhibit triggered to notify that it is time to load data
dataLoaded.exhibit triggered once all data has been loaded (or load failed)
Although this change would be consistent, I'm not convinced that this fully event-driven model is wise; it creates a lot of confusion about order of execution as events depend on other events in non-transparent ways. It also relies very heavily on the exact semantics of JS event triggering to be sure that events that are not listening for each other still trigger in a predictable order---namely, that all events triggered in one thread are handled before any events that are triggered in a later thread. This is assuming a lot more than single-threading.
As one example of both the assumptions and the non-transparency, final.js the scriptsLoaded.exhibit event and uses it to trigger the registerStaticComponents.exhibit event which leads to importers being configured. These importers must be configured before we actually load the exhibit data; however, they provide no signal that their configuration is done. Thus, to time the loading of data properly, our approach is to make sure that the data loading is caused by an event that is triggered later, and rely on the fact that events are handled in triggering order.
The text was updated successfully, but these errors were encountered:
Much of exhibit has been modified to manage scheduling using event triggering and listening. The database layer stands out in that it is still using continuations. More consistency would hold if the db layer were also modified to listen for and trigger events. Looking to the current event model, the obvious events would be
loadData.exhibit triggered to notify that it is time to load data
dataLoaded.exhibit triggered once all data has been loaded (or load failed)
Although this change would be consistent, I'm not convinced that this fully event-driven model is wise; it creates a lot of confusion about order of execution as events depend on other events in non-transparent ways. It also relies very heavily on the exact semantics of JS event triggering to be sure that events that are not listening for each other still trigger in a predictable order---namely, that all events triggered in one thread are handled before any events that are triggered in a later thread. This is assuming a lot more than single-threading.
As one example of both the assumptions and the non-transparency, final.js the scriptsLoaded.exhibit event and uses it to trigger the registerStaticComponents.exhibit event which leads to importers being configured. These importers must be configured before we actually load the exhibit data; however, they provide no signal that their configuration is done. Thus, to time the loading of data properly, our approach is to make sure that the data loading is caused by an event that is triggered later, and rely on the fact that events are handled in triggering order.
The text was updated successfully, but these errors were encountered: