Solid/LibSolid/asyncAPI: Difference between revisions
Created page with "For Frameworks 5 (the next version of libsolid) we want to add an asynchronous api to libsolid. This is needed because we will be adding network base backends and those can't be ..." |
No edit summary |
||
| Line 1: | Line 1: | ||
For Frameworks 5 (the next version of libsolid) we want to add an asynchronous api to libsolid. This is needed because we will be adding network base backends and those can't be based in the current synchronous api. | For Frameworks 5 (the next version of libsolid) we want to add an asynchronous api to libsolid. This is needed because we will be adding network base backends and those can't be based in the current synchronous api because they are not as fast as they should be, and anyway even if they were fast enough we will probably have up to 5/6 backends active at the same time so we better asynchronize it. | ||
== Current problems == | == Current problems == | ||
The problems can be basically separated in two categories, backend and frontend. | The problems can be basically separated in two categories, backend and frontend. | ||
In the backend we are currently iterating through all backends and calling "getDevice". That's ok since now we only have local backends and they are supposed to be fast | In the backend we are currently iterating through all backends and calling "getDevice". That's ok since now we only have local backends and they are supposed to be fast. The situation changes if we add network based backends into the formula since those, won't be as fast and in anyway if we're going to support the creation of new backends we can't continue blocking the process until each of the backends finish the "getDevice" call. | ||
The proposed solution looks like follows: | |||
WIP page | |||
Latest revision as of 18:34, 2 October 2011
For Frameworks 5 (the next version of libsolid) we want to add an asynchronous api to libsolid. This is needed because we will be adding network base backends and those can't be based in the current synchronous api because they are not as fast as they should be, and anyway even if they were fast enough we will probably have up to 5/6 backends active at the same time so we better asynchronize it.
Current problems
The problems can be basically separated in two categories, backend and frontend.
In the backend we are currently iterating through all backends and calling "getDevice". That's ok since now we only have local backends and they are supposed to be fast. The situation changes if we add network based backends into the formula since those, won't be as fast and in anyway if we're going to support the creation of new backends we can't continue blocking the process until each of the backends finish the "getDevice" call.
The proposed solution looks like follows: WIP page