This page relates to version 1 of 529renew, which was based on the webSQL database API.

It is now obsolete, because the process with sqlite-wasm imposed major changes.

triangulation sequence

The process is so convoluted, with switching between 23andMe and extension space, mesage passing, and callbacks across each space, that I have to make these notes to remind myself.. Code refers to three people:

1. Profile person (you or somebody's whose kit you manage)
2. Match person - the DNA relative at the top of the page
3. relative_in_common. - the other testers who are ICW the first two.

Initiation

It starts in the content script save_segments.js with a click on the tr_el button.

1. saves status of shift and Alt keys.
2. sends message to extension to get delay (and potentially other) settings, value returns via
3. value returns via message, which calls
4. process_qDelay(), which then enters the main process of..
5. runComparison() (formerly called RunComparison3() - I think there were two previous functions that worked on older page 23andMe formats).

Main loop - runComparison()

1. scans the current list of (up to 10) matching ICW relatives and prepares a queue of two-way chromosome browser comparisons to run: each record in the queue includes the two names and their UIDs. The comparison between profile and match is included only once, and it adds one entry for profile to ICW relative and another for Match to ICW-relative.
2. The comparisons are run by default only for ICW with overlapping segments, but if shift was held down then all chromosome matches are compared and saved.
3. ICW matches are always ignored if they are not revealing their DNA segments.
4. It then calls launch_next_IBD_query() requests all data in the queue, and once the queue is empty jumps to the next page.

queue processing

1. launch_next_IBD_query() gets the next entry off the queue and calls run_query() with paired UIDs and names
2. run_query sends message to extension, with request to "checkIfInDatabase" and ID info, plus "skipDBQuery" set to False.(why?) It inlcudes mode:"checkIfInDatabase" as well as checkIfInDatabase:true. Since both places that make this call use the constant true, it seems redundant - the latter is never checked- removed after V1.0.0
3. calls countMatchingSegments() with callbacks on success or failure back to inline functions.
4. In all cases, the reply is eventually passed by message to the initial calling tab, with mode:"returnNeedCompare and needToCompare:<an appropriate boolean value> The value of needToCompare determines if a request is made to the 23andMe servers - false implies we already have the information.

countMatchingSegments(id1, id2, callbackIfQueryOK, callbackOnFailure)

Gets the number of segments in the DB between the two specified testers and passes the result to the callbackIfQueryOK function

The callback function then evaluates the number of matches counted and if > 0 then sets needToCompare as false. In all other cases, needToCompare will be set true.

response message with mode: "returnNeedCompare"

Back in the content script (save_segments.js)...

1. build URL request for segment match data
2. wait the delay time
3. send request, passing return to internal callback function makeSegmentSaver()
4. parse segment data from response and send message mode:"storeSegments" to extension, together woth object with segment data.
5. call launch_next_IBD_query()

StoreSegments

1. The message listener in the extension sees the request with `mode:"storeSegments"
2. calls storesegments(), which..
3. adds the ID of the person, if new.
4. adds the reported segment(s)