On 6/9/06, Christian Perrier <bubulle@debian.org> wrote:
However, my understanding is that the main intent behind the "separate backend from frontend" work is to allow further changes in implementations without redesigning the whole thing. In short, if a correct API is implemented for storage, then I guess that different storage modules could be hokked in this API to allow storage either in a RDBMS, or as flat file, or other possible storage methods for the data.
Indeed you are right and the best course of action (in my mind) is separating the system into three parts: frontend, middleend and storage with defined APIs in between, but discussion of even the possibility of having a database as one of possible backends is important at this stage as it would recommend a different API between middleend and backend. The most efficient way that I see is to plan this API with the functionality of databases in mind, so that their optimised low level code can be used to maximum benefit, but that would mean that there will have to be quite a bit of functional code in the file backend module. That is the main tradeoff. -- Best regards, Aigars Mahinovs mailto:aigarius@debian.org #--------------------------------------------------------------# | .''`. Debian GNU/Linux LAKA | | : :' : http://www.debian.org & http://www.laka.lv | | `. `' | | `- | #--------------------------------------------------------------#