Closed jonathanrobie closed 3 years ago
There are two logical possibilities here.
So I could imagine ...
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?
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.
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.
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.
Another use case I would like clarity on. In this use case, I am interested in identity and revision management in this scenario:
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.