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

[Teus Benschop]

Update of task #8022 (project bibledit):

                  Status:               Need Info => Postponed              

    _______________________________________________________

Follow-up Comment #4:

Thanks you all for commenting on the matter.

Adding the various comments that have been made. This is done regardless of
content, for archival purposes:

Comment #1

This is unfortunate but not surprising for UBS to take this stance. In my
opinion would be just as well to put this feature request aside until the
Chorus collaboration tool is implemented and people can use that for working
with repositories in a collaborative way. Once that happens I think the way
many look at handling data collaboratively will change. I think this is one of
those issues that will solve itself over time. Just my opinion though so my
vote is to abstain. ;-)

Comment #2

Did Nathan give any reasons for his request? If all programs conform to the
USFM standard data files, why does it matter what "client"  program submits a
change to the repository? Presumably the repository  manager assigns
permissions to trustworthy users. And presumably it  already handles multiple
clients/users making changes to common files  which is the main thing that
repositories are all about.
I don't really understand this. It seems like a really useful 
feature to me and could help us as an interim step in making the change away
from expensive and proprietary operating systems.

Comment #3

You may be interested in the work that John Hatton and our group here are
doing with collaboration.  We have a project underway called 'Chorus' that is
effectively a nice UI over mercurial (or some other distributed version
control system).  It provides an API so that programs can easily support DVCS,
and merge - particularly delaying the conflict resolution to a more convenient
time.

For a repository we are working on using something like redmine
(www.redmine.org) to manage a web based repository.

Further details on chorus can be found here:

    http://projects.palaso.org/projects/show/chorus

Chorus is incorporated into the 0.5.x versions of wesay.

    http://wesay.org/downloads/

Comment #4

It seems to me that it won't matter how many votes you get for this 
feature if one of them isn't from Nathan Miles.

However, if Bibledit and Paratext both support USFM, it seems to me that it
should be possible and desirable to build our own heterogeneous environment
collaboration repository tool that worked with both programs (and any others
that use USFM). The result would be maybe a bit less smooth for Paratext
users, but it would not burden Nathan with compatibility issues as much. (He
would still have to deal with any issues that might be caused by deviations
from the USFM specification, but since his input into that spec is
predominant, I don't expect much of that.)

Comment #5

I think, if I’m reading this right, you’re missing what Nathan is saying.
 Forget “votes”.  UBS is saying, don’t add a feature to BibleEdit to use
our repository.

There is very good reason for Nathan to not want other apps to be touching
the PT7  repository at this time.  In addition to whatever Nathan is thinking
about (like their current security model which won’t work with open source),
there are complications related to PT and Chorus’s ability to postpone
conflict resolution, deal with multiple repositories & multiple heads (in the
case of PT) and just multiple heads in a single repository (Chorus).  Both
systems go to a lot of work to avoid forcing a particular user to resolve
conflicts when he/she syncs with the rest of the team (via usb stick, LAN, 
internet, or radio email).  They allow anyone on the team, anywhere, to do the
resolving for the rest of the team, at their convenience.  This is major
breakthrough, but it comes with some complication for developers.  Chorus goes
further… while PT handles this by running the merge inside PT, Chorus does
it straight from Mercurial (which sees it as a merging program), which allows
files from multiple language programs to all live in the same repository. 
With PT7’s approach, you must have only USFM and other PT7 data in there,
and you must use PT7 to do the synchronization.

I’m not up to explaining much more at the moment, but once you go down the
path which PT and Chorus have gone, it may not any longer just a matter of
just making use of the repository using Mercurial (though read-only access
would be fine if not for the security problems).  There are rules the app will
have to abide by, and what those rules even *are* wouldn’t be in concrete
while the tools are in development.  Conceivably UBS could decide to publish
its rules, allowing other apps to participate once the security model is
changed.  But you can see why now, during their alpha tests, would not be the
right time for the PT team to go that route.

For this and many other reasons, I do believe we’re in for pain unless we
all use the same DVCS wrapper which embodies all these rules in real, open
source, fully unit-tested code.  Chorus, which is not ready for prime-time
either, is offered as that common system.  It is single exe which is called by
mercurial as a “merge specialist”.  That same exe is seen as a library to 
.net client apps, for whom it hides all the complexity; those apps won’t
even know if hg, git, or something else is actually being used.  The .net apps
that could use it includes FLEx, OurWord, Phonology Assistant, PT7, WeSay,
DictionaryExpress (forthcoming), LiftTweaker (forthcoming).  If we wanted to
include the C/C++ apps in the stable (BibleEdit and AdaptIt), then it could be
made fully functional for client use from the command line.

So, I think an open system like Chorus is the answer, but so long as the big
guy on the block (PT) is using a proprietary system, it may be difficult for
little guys like BibleEdit, TE, AdaptIt, and OurWord to play in the game.  But
they could all play with each other, and with all of our linguistic apps.

Comment #6

Given that the inability to use the same repository could be a serious
impediment to choose the best tool for each person concerned and the inability
of Paratext to run natively on a free platform, I think this "specific
request" should be ignored. It is infuriating and appears inappropriate to
make.

The requester himself should consider carefully his motives. If they are
solely about "support" then this is probably best addressed by having a
carefully considered and documented structure and specification, which would
make independent faithful implementation simple - as long as no deliberate or
careless quirks are introduced in the "other" implementation.

Unless there are legal reasons to do so, please ignore this "specific
request"

AFIACT Reverse engineering is specifically allowed in Eropean
legislations. But IANAL etc.


    _______________________________________________________

Reply to this item at:

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

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