[be] [task #8022] interoperabillity with other content managers

[Teus Benschop]

URL:
  <http://savannah.nongnu.org/task/?8022>

                 Summary: interoperabillity with other content managers
                 Project: Bibledit
            Submitted by: teus
            Submitted on: Friday 04/18/2008 at 19:05
         Should Start On: Friday 04/18/2008 at 00:00
   Should be Finished on: Friday 04/18/2008 at 00:00
                Priority: 5 - Normal
                  Status: None
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

My view on this one, after thinking about it, is the following (there's no
boss above me a regarding programming work, but there is a HOD for
translation, so as far as the programming is concerned there is true anarchy
here and full freedom, following the tradition of the good old open source
founders   :-)   ):

1. It is not good to enforce one particular content management system upon
programmers, whether svn, git, emailed patches, hg, bzr, cvs (oops, is that
one still alive?), etc. We don't enforce programming languages so why enforce
content managers? Instead of that let each translation system select his own.

2. Even if we had agreed on one content manager, then after many years a
grass-root project might spring up out of the ground and do very well, and
overtake any existing translation software that now exists. It might have
chosen its own content manager, and so by overtaking all might enforce its own
type of workflow, making anything else fade away.

3. It is very desirable if the various translation softwares could work
together, that is, data can be interchanged and people can collaborate in the
same translation project using different software, yet being able to
collaborate.

4. When looking at Windows / Linux interoperability, we might learn a lesson
from there. It has happened in the past that one platform adapts to the other
platform's standards so as to establish the possibility of interoperability.
Think of the samba project for example.

5. Taking all of the above in account, my view is that each translation
software should carry on in the path it already has chosen. To enable
collaboration between different content managers, and different layouts within
each system's repository, all working on the bible, it would not be difficult
to create a small application that sits in between all of these. It could pull
in changes from one type of repository, e.g. from git, and merge them with its
own project data. Then it could pull in changes from the other type of
repository, most likely hg, and merge these too. Then it would push the
changes back to both repositories. Conflicts could be resolved automatically
(e.g. take "git" or take "hg"), or manually. If ten people collaborate on one
project, then there would be only one workstation or server that runs the
above glue application.

6. The world is varied and so are the views of people. One person wrote git
and the other person didn't like git's processing model, so wrote hg. That's
how the world works. Rather than trying hard to change that situation, and
discovering that it is going to fail, I recommend the above workaround.

Teus.


----------------------------------------------------------------------

Comment By: Teus Benschop (teus)
Date: 2008-04-07 19:02

Message:
Logged In: YES 
user_id=890881
Originator: YES

For linking to Paratext repository, consider a daemon that does the
transfers per
chapter / book, a deamon of bibledit that bridges git and hg.

It probably is a separate module that runs once somewhere and does the
bridging.

It does not run with every instance of bibledit, but only once.

Nathan Miles has been asked for a development version of Paratext 7.


----------------------------------------------------------------------

Comment By: Teus Benschop (teus)
Date: 2008-04-03 12:52

Message:
Logged In: YES 
user_id=890881
Originator: YES

The layout of the repository is the same as the layout of the original
data. The data storage layout has not changed from
P6 to P7 except that there are a few more .xml files (project progress,
project notes, etc.) living in the project directory. Paratext keeps
everything unique to a project it's own flat directory. Things shared by
multiple projects are kept in \My Patratext Projects (stylesheets, language
info). These shared items are placed into a project subdirectory called
"Gather" in order to get them into the repository. 





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?8022>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/