search

bible-technology / scripture-burrito

Scripture Burrito Schema & Docs 🌯
http://docs.burrito.bible/
MIT License
21 stars 13 forks source link

Use Case: Autographa, Paratext Client, Paratext Send/Receive Server #231

Closed jonathanrobie closed 3 years ago

jonathanrobie commented 3 years ago

Another use case I would like clarity on. In this use case, I am interested in identity and revision management in this scenario:

  1. Autographa creates a project and adds it to the Paratext server
  2. The Paratext client receives that same revision, edits it, and sends the new revision to the Paratext server
  3. The Autographa client receives that revision, edits it, and sends the new revision to the Paratext server

I assume that the people using these two clients may be sitting right next to each other working on the same project and it is important for them to be able to establish that they are.

jonathanrobie commented 3 years ago

There are two logical possibilities here.

  1. If the server does not change the Burrito, it could simply forward the last Burrito that was uploaded. Or, more likely,
  2. The send/receive server is likely to add information, so it should clearly identify the source burrito and create a new identifier. As long as the source burrito is identified, users can see which send/receive project corresponds to it. In this design, a client that uploads a new burrito should also identify its source burrito, the last revision of the project that it got from the send/receive server.

So I could imagine ...

  1. Autographa creates a project with an identifier, a revision number, and a date. There is no source at this point.
  2. Autographa uploads this to the send/receive server, which creates a new burrito with additional metadata, identifying the Autographa burrito as its source, creating a new identifier, revision number, and date.
  3. The Paratext client receives this burrito from the send/receive server. When the next revision is uploaded, the client identifies its source using the identifier, revision number, and date from the server's burrito and creates its own identifier, revision number, and date.

This works but it's a little fiddly. I think that's a consequence of having the revision number and date inside the burrito. And I think our use cases probably require that. We could simplify handling we did not need that. In practice, each of these steps probably involves unzipping and zipping, so there's a real performance hit.

Is there a better way?

FoolRunning commented 3 years ago

I'm not sure how likely your scenario is since Paratext has no plans to allow SBs directly on a server (S/R or Registry). It will only be an import/export to/from the Paratext application itself.

jonathanrobie commented 3 years ago

At the PPC, we agreed to do a server-side SB API for Paratext, so I think this is relevant.

Obviously, Paratext and Autograph will each work with data in their own internal formats, so I guess the zip/unzip overhead is inherent regardless, that's not an issue. So my original comment was off-base on that issue.

jonathanrobie commented 3 years ago

At this point, I think the server-side SB API for Paratext should simply do import / export and not attempt to do Send/Receive. I would like to close this issue without action.