Re: [translate-pootle] [Fwd: Re: Wordforge]
Hi Otavio, Guintautas,
I would like to propose a course of action.
1.- Gintautas works on the API (which has to include the separation of
front-end and back-end), and on the XML-RPC. This will really clear up
things for further work, and will facilitate the specification of a DB.
This work is done in a separate branch, as required by the project.
2.- The WordForge present staff will integrate these changes in Head as
soon as they are clear, so that Gintautas' branch and Head stay as close
as possible, and integration is not a problem later.
3.- Independently of the work that is continuing on WordForge (front-end
or file-based back-end), WordForge will be happy to fund somebody to
work on designing and implementing a RDB back-end. This can be somebody
working on parallel during the coming months, or Guintautas after he
finishes (if he has time before going back to school). Then we just use
-or continue working on-the best back-end that we have. We would work
together with this person to ensure that all the data that we need in
the project is present in the DB (even if most of should be defined
already defined by the API).
I somehow have a feeling that the optimal result will be something
between file-based and DB based, again, I could be completelly wrong. We
will not really know what it is until we try.
Some more comments below.
Otavio Salvador wrote:
Gintautas Miliauskas <gintas@akl.lt> writes:
I fully agree with you that we should avoid to store data directly on
files also because if we later discover another format will be very
difficult to reuse old data and we'll need to make converters for
it. So, let does it from basic design.
I have to disagree with this. Independently of if the best storage is
files or DB, the standard formats are precisely done so that they will
last for a long time. XLIFF is an OASIS standard that will evolve, and
will not be replaced in the coming decades. Same as Unicode, the
standards are there to last... and, even if change, happened, you would
still need to write converters. On the contrary, when these standards
advance (within backwards compatibility), you will have to modify the
database to admin new types of information, but you would not need to
modify a file-based system
I agree about the idea to have a "server layer" between the client and
backend because it makes trivial for user to use the backend without
much hassle and without the need to control locks and whatever of
internal details of it.
Makes a lot of sense.
One thing that come to my mind just now is that we might have the
following design:
|--------------------------------------|
| | Pootle itself |
| Clients |----------------------------|
| | Pootle compatibility layer |
|--------------------------------------|
| XML-RPC server | Other servers |
|--------------------------------------|
| API to access the data |
|--------------------------------------|
| RDMS with data |
|--------------------------------------|
Adding a little more meat:... Also, I would see the a separation between
the Pootle web-based file server and the Pootle editor, and maybe
putting them on top of the API, even if maybe this is not the best place
for the editor. Would this break the idea that you expressed with the
server layer above?
|-----------------------------------------------------------------------------|
| Clients | | CVS/SVN |
| Other Pootle | | FOSS projects |
| servers | | |
| Rosetta | Translators Reviewers, etc. | |
| Off-line Editors| | |
| Compiler farm | | |
|-----------------------------------------------------------------------------|
| XML-RPC server | Pootle file Server| Pootle Editor| Other servers + filters|
|-----------------------------------------------------------------------------|
| API to access the data |
|-----------------------------------------------------------------------------|
| RDMS with data | File based System | Other back-ends? |
|-----------------------------------------------------------------------------|
With that in mind I realise that might be easier to get colaboration
of Pootle people since they can help us to design the layers bellow of
their compatibility layer and at same time improve their system in a
easier way without the needed careful to don't brake our system. So,
with that we both are basically free and able to help each other.
I agree, you can count on all our help.
The only drawback on it that I can see is that we won't contribute
much code back to Pootle directly. Basically fixes to get it more
"backend agnostic" and then plug our backend there. That, IMHO, is a
good conseguence since they'll be free to choose and develop other
backends without the compromise to us just one.
Our idea -as I mentioned- is still that we work together in the
different options. We would not like to see an "our back- end" and a
"your back-end". The advantage of working together is that there are
more people thinking, and the good news is that we have sufficient
funding to look at both options, and then pick up the one that we all
agree is the best, and continue working in that direction.
Javier
Reply to: