- #Jabref email update
- #Jabref email Offline
#Jabref email update
CHANGE (an entry is modified in JabRef locally): Increase its local version number and update its hash. If not, increase the local version number and update the hashed entry. LOAD (JabRef is started and reads the library with sync information): For each entry, check if the the stored hashed entry coincides with the hashed version of the entry in the bib file. Then the sync operations are implemented as follows: On server side, the "shared id" and a "server version number" is stored. A "hashed entry" representing the entry at the point when the local version number has been increased the last time. A "local version number" that represents the local version of the entry, and which is increased as soon as the entry is modified locally. A "client version number" that represents the version of the entry the last time the client synced with the server. A "shared id" which uniquely identifies the entry for sync purposes. In particular, we can always ask the user to resolve conflicts and don't need automatic conflict handling.įor each entry, we store the following data on the client side: A10: The data stored in one entry is relatively small (300-500 bytes), but there may be many entries so that the total library is usually a few mb. there is no "main" device that can be considered to be the single source of truth. A9: Users may edit the library on any device, i.e. A8: Users can change the bib file manually outside of JabRef, and changes should still be successfully transmitted to the server. A7: All data that we want to transmit needs be saved in the users library, at least to the extend that the bib file should work as a snapshot from which the user can start working without loosing data. #Jabref email Offline
A6: Users may go offline for some time, without transmitting their data to a central server before. A5: Users may try to edit the same data at the same time (though this should happen rarely for our current user numbers). A4: Users should always be able to edit their own databases, since otherwise their local workflow with latex compilation is not possible (offline-first). A3: Data correctness is valued very highly. A2: Conflicts may be resolved manually since JabRef already has a nice 2-way merge interface and conflicts shouldn't happen that often to annoy users. 
But it is not as common to have conflicts as for example in collaborative text editing. In S2, multiple users may completely revise the entry independently. read status) or that the users changes an entry on one device while having forgotten that she made a similar change already on another device. In S1, it seems most probable that some metadata changes on multiple devices simultaneous (e.g. A1: Conflicts at the level of one entry are relatively rare.JabRef's requirements are summarized as follows: teacher > student, students only have read rights author > coauthor, all have write privileges). S2: Multiple users accessing the same database: In the future, it would be nice to share one or multiple entries (or all) with other people, giving them different rights (e.g.JabRef's central server may been seen as one of these "user devices".
A device may go offline at any point and may reconnect at a later time. S1: One user, multiple devices: One user may have different devices with JabRef installed and would like to sync the library across all devices.
With the upcoming implementation of an online version for JabRef, we face the issue of synchronizing data across multiple devices (and eventually different users).
0 kommentar(er)
