On 6/9/06, Christian Perrier <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux LAKA |
| : :' : http://www.debian.org & http://www.laka.lv |
| `. `' |
| `- |
#--------------------------------------------------------------#
_______________________________________________
Translate-pootle mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/translate-pootle
