Gintautas,You have to talk to Friedle and David, but the idea is to do the separation on what is there now, using the work and classes that Friedle and David are doing. They have been putting a lot of work on the base classes, we should only get into new ones if they are for a different purpose. As Dwayne mentioned, these clases could easily be adapted later for other type of storage (the DB), but that is the future, we now should concentrate on the SoC project.
My impression is that you should now: 1.- Specify what the API should do, what services is should render upwards.2.- Draw very clearly the line between the present back-end and what is above it and develop the API from above to the present back-end, remaking the direct conections through the API.
3.- Document this API, as it should be the same for all possible back-ends.4.- Write the XML-RPC. This will take some time, as different scenarios probably need to be considered (if it pushes data or demands data from other places).
I don't know Python myself, so I cannot help on the details, and maybe some of the things that I say do not make any sense, I don't know if what I am saying is in agreement with what you wrote, but I assume that by "the new back-end" you mean the API, in which case we seem to agree. If so, I think that we are in the same mind-frame.
But I am just a theory man, at the end the ones that know what is happening are Dwayne, Friedle and David. I believe that if you work in close cooperation with them, there will be plenty of time to work on the separation, API and XML-RPC, and to integrate it in HEAD, so that in September we are prepared to start thinking about writing and integrating a database back-end with the same API. I would prefer to wait until the API is implemented before we start thinking about this, as specifications may change (be improved) during implementation.
Javier Gintautas Miliauskas wrote:
Hello,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 ...I like your plan very much. I have one question: how to best approach migration to the new backend? Doing it in-place would unnecessarily break a lot of things until the entire job is complete. I am thinking of this process: 1) introduce a new Python package, e.g., Pootle.backend or Pootle.storage 2) define interfaces (abstract classes) 3) define implementations, gradually move code into them from the main server, update original code to use the new backend 4) remove all remaining direct access code so that data is accessed only through the backend. Do you think this plan makes sense?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? <snip>Yes, this scheme is almost exactly what I was thinking about. Indeed, the Pootle file server is different from the Pootle online editor and they should be separate.------------------------------------------------------------------------ _______________________________________________ Translate-pootle mailing list Translate-pootle@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/translate-pootle