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
The SubscribableRequestQueue has one main API problem: you can pass different actions in under the same key and id. And there is no way for the caller to know that their action may never be invoked.
Solution
Clean readable maintainable and understandable api's.
There isn't really an action item here apart from considering if we can re-engineer the caching and chunk fetching logic to be simpler while still handling the features we need (cancellable batches of chunk fetches, etc)
One thought experiment is to try inserting a proxy chunk in the cache before issuing the fetch. Then there is extra bookkeeping around cancellation but it might eliminate the need for the SubscribableRequestQueue.
The other idea floated in our discussion was to use a less object-oriented and more "database oriented" api and code flow.
The text was updated successfully, but these errors were encountered:
Use Case
The SubscribableRequestQueue has one main API problem: you can pass different actions in under the same key and id. And there is no way for the caller to know that their action may never be invoked.
Solution
Clean readable maintainable and understandable api's.
There isn't really an action item here apart from considering if we can re-engineer the caching and chunk fetching logic to be simpler while still handling the features we need (cancellable batches of chunk fetches, etc)
One thought experiment is to try inserting a proxy chunk in the cache before issuing the fetch. Then there is extra bookkeeping around cancellation but it might eliminate the need for the SubscribableRequestQueue.
The other idea floated in our discussion was to use a less object-oriented and more "database oriented" api and code flow.
The text was updated successfully, but these errors were encountered: