[be] [ bibledit-Feature Requests-1932239 ] interoperabillity with other content managers

[SourceForge.net]

Feature Requests item #1932239, was opened at 2008-04-02 15:48
Message generated for change (Settings changed) made by teus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=658624&aid=1932239&group_id=111189

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Teus Benschop (teus)
Assigned to: Nobody/Anonymous (nobody)
Summary: interoperabillity with other content managers

Initial Comment:
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. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=658624&aid=1932239&group_id=111189