Use Case: Is this Burrito new?

jonathanrobie commented 4 years ago

Implementation Need

Suggestion is that we add a timestamp field to idAuthority. The timestamp should reflect the idAuthority's revision control system, e.g. the timestamp of the revision noted.

See more details below.

History

An editor like Paratext has created a new revision. The user wants to synchronize with the DBL server. The server has received the Burrito and wants to know if it is new or an existing resource.

How is this done?

One possible approach:

The Scripture Burrito for the client's project contains the latest revision date / time and the latest revision identifier, perhaps drawn from some source code control system.
The server extracts the date/time and revision number for the last revision of each project for each resource and stores it in a convenient place.
When an exchange is requested, the client and server compare the latest revision number and date for the project to decide whether this is a new revision or not.

FoolRunning commented 4 years ago

Can't it just look at the date/time of the SB?

jonathanrobie commented 4 years ago

Suppose I create a new Scripture Burrito, but nothing in the contents has changed. What should happen?

On Thu, Jul 30, 2020 at 11:15 AM Tim Steenwyk notifications@github.com wrote:

Can't it just look at the date/time of the SB?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/208#issuecomment-666444535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPMCABW5ZVJALKYNOSLR6GFB7ANCNFSM4PN4OYMA .

FoolRunning commented 4 years ago

If you mean what should happen as far as identification is concerned, then I would think the project identification and revision of both burritos would be the same. The fact that they have different dates shouldn't matter much as far as DBL is concerned. DBL would just accept it as another revision and it would happen to have the same contents as the previous revision.

Tim Steenwyk

Software developer SIL Language Software Development tim_steenwyk@sil.org

On Thu, Jul 30, 2020 at 3:39 PM Jonathan Robie notifications@github.com wrote:

Suppose I create a new Scripture Burrito, but nothing in the contents has changed. What should happen?

On Thu, Jul 30, 2020 at 11:15 AM Tim Steenwyk notifications@github.com wrote:

Can't it just look at the date/time of the SB?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/bible-technology/scripture-burrito/issues/208#issuecomment-666444535 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AANPTPMCABW5ZVJALKYNOSLR6GFB7ANCNFSM4PN4OYMA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/208#issuecomment-666638989, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAIVTCIZC5EJFTQGWFSTZLR6HD6NANCNFSM4PN4OYMA .

jag3773 commented 3 years ago

Lots of possibilities here but I think that SB spec currently supports enough ways to do this currently (including checksums on ingredients).

smorrison commented 3 years ago

In DBL currently, it's DBL that assigns a revision number (revision of previous entry with same PT project ID + 1). Dates are not considered (although we capture the date that it's received), for the same reason that you can't compare files on disk using creation date.

If we're going to have a single identification section, then it's important that (e.g.) PT puts a revision identifier that's unambiguous

jonathanrobie commented 3 years ago

This is really a question of integrity constraints with respect to the identifier. If two burritos are identified as "the same" but their contents differ, there's a problem with referential integrity.

The specification should clearly tell us how to identify (1) two revisions of the same project, (2) two burritos that both represent the same revision of the same project. Given two burritos for the same project, it should be easy to know which is newer. I think it should probably tell us this: the systemId provides the identifier and revision number, if two burritos have the same systemId (including revision) then they should have the same content, if not, all bets are off (semantics are undefined according to our specification).

Revision numbers are comparable, a larger number is considered later than a smaller number.

"systemId": {
  "dbl": {
    "id": "2880c78491b2f8ce",
    "revision": "91"
  }
},

On Thu, Nov 5, 2020 at 12:05 PM Jesse Griffin notifications@github.com wrote:

Assigned #208 https://github.com/bible-technology/scripture-burrito/issues/208 to @jonathanrobie https://github.com/jonathanrobie.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/208#event-3963461451, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPJUYSPBG6QWH4VEVV3SOLLL5ANCNFSM4PN4OYMA .

jag3773 commented 3 years ago

Narrative:

Paratext creates a burrito and uploads to the DBL with a systemId like so;

  "ptx": {
    "id": "ksdjoiejfs",
    "revision": "ljksdfo8jkm",
    "timestamp": "2020-11-19-11:30"
  }

DBL receives that and adds it's own DBL systemId:

  "dbl": {
    "id": "2880c78491b2f8ce",
    "revision": "1"
  }

now, DBL receives another upload like this:

  "ptx": {
    "id": "ksdjoiejfs",
    "revision": "ljsdf8",
    "timestamp": "2020-11-19-11:18"
  }

DBL creates a new revision like so (even though the most recent upload is from an earlier Paratext commit):

  "dbl": {
    "id": "2880c78491b2f8ce",
    "revision": "1"
  }

Suggestion is that we add a timestamp field to idAuthority. The timestamp should reflect the idAuthority's revision control system, e.g. the timestamp of the revision noted.

jtauber commented 3 years ago

Is the timestamp required or optional? (in the narrative, it's not always present)

jtauber commented 3 years ago

Is this timestamp for the overall SB sufficient for this use case?

jag3773 commented 3 years ago

In my review of the spec and the suggestion here, I think we should include timestamp as an optional field in idAuthority. I can see how it would be useful for an app to be able to see that information for each idAuthority that is listed.

jonathanrobie commented 3 years ago

I think the timestamp is sufficient. Any reason not to make it required?

Jonathan

On Mon, Dec 14, 2020 at 1:18 PM Jesse Griffin notifications@github.com wrote:

In my review of the spec and the suggestion here, I think we should include timestamp as an optional field in idAuthority. I can see how it would be useful for an app to be able to see that information for each idAuthority that is listed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/208#issuecomment-744620736, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPICBYT3KFT5GRRQFP3SUZJIRANCNFSM4PN4OYMA .

jag3773 commented 3 years ago

@jonathanrobie which timestamp are you referring to in your comment?

jonathanrobie commented 3 years ago

This timestamp:

"ptx": { "id": "ksdjoiejfs", "revision": "ljksdfo8jkm", "timestamp": "2020-11-19-11:30" }

On Tue, Dec 15, 2020 at 4:27 PM Jesse Griffin notifications@github.com wrote:

@jonathanrobie https://github.com/jonathanrobie which timestamp are you referring to in your comment?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/208#issuecomment-745578244, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPJ4VP36PWYYOSPNY2TSU7IEPANCNFSM4PN4OYMA .

jag3773 commented 3 years ago

Agreed today that we will make this required.

jtauber commented 3 years ago

I've captured the action on the spec in #234. Close this issue?

jag3773 commented 3 years ago

Further discussion may happen in #235 .

bible-technology / scripture-burrito

Use Case: Is this Burrito new? #208

Implementation Need

History