improve handling of awars containing tree names

[westram]

awars containing names have several problems:

• if a callback is bound to the awar it is only triggered if a different is selected. often we also want it to trigger, when the referred itself has changed.
• if a gets renamed or deleted, the awar still points to a nonexistant . Instead it should
  • automatically switch to the new (in case of a rename) or
  • be reset (to ""?) in case of a delete

[westram]

How to reproduce a crash caused by this problem:

• start demo.arb
• open new window (both windows show tree_test now)
• open admin
• rename tree_test into tree_new (main window switches to tree_new, 2nd remains with tree_test)
• in 2nd window select 'set root mode' and right click into display .. bye bye

This is just one example - i think all ARB apps are affected in many situations

[westram]

by [11506]

[epruesse]

Wouldn't the same issue also occur with other referenced objects? To mind come

• species
• alignment
• pt server (unlikely, but arb_tcp.dat can change)
• database fields

Naively, I'd approach this by making the respective AWARs "selection lists". AWAR doesn't support this yet, but we have the concept of "defined ranges" for AWARs with "min/max" for scalars, so it'd be logical to have a "defined value list" given by some path in the . So something like

awar_string("ARB_NT/current_species","?")→selects_from("species_info/species","name") awar_string("ARB_NT/current_tree","?")→selects_from("tree_info")

which should make the AWAR itself watch the respective -folder for changes and revert to default if its value becomes invalid due to removal, ideally even change if the value changes.

Complications will be lists of the "species/name" type vs. the "/tree_xxx" type, and of course recursive notification callbacks in the .

And … while I'm on the topic of AWAR/future: Are there any reasons why we have to have multiple AWAR databases? If we had only one, the entire "remote awar" thing would no longer be required. It's not clear to the anyway where the "application boundaries" lie: the EDIT4 window appears to be as much as subwindow of ARB_NT as SEARCH_AND_QUERY is. The only place where specific use is made of different awar databases is in EDIT4 with the alignment and sequence-type specific settings (which I doubt anyone but WL understands and uses).

If at all, this would be something to do post-GTK-merge, of course.

[westram]

Replying to epruesse:

Wouldn't the same issue also occur with other referenced objects? To mind come

• species
• alignment
• pt server (unlikely, but arb_tcp.dat can change)
• database fields

Naively, I'd approach this by making the respective AWARs "selection lists". AWAR doesn't support this yet, but we have the concept of "defined ranges" for AWARs with "min/max" for scalars, so it'd be logical to have a "defined value list" given by some path in the . So something like

awar_string("ARB_NT/current_species","?")→selects_from("species_info/species","name") awar_string("ARB_NT/current_tree","?")→selects_from("tree_info")

which should make the AWAR itself watch the respective -folder for changes and revert to default if its value becomes invalid due to removal, ideally even change if the value changes.

That doesn't fit into the AWAR-API, it fits better into some AWAR-registry (with one registry for each item-type referred to: trees, alignments, ptservers, field-names), because then one -callback can serve all registered members (opposed to the need to bind one callback for each single AWAR).

A second thing are the selection lists themselves: One AWAR may often binds to multiple selection lists, but when e.g. adding a alignment, all alignment-selection-lists need to update. Currently all alignment-, ptserver- and -selection-lists are registered (as AW_DB_selection) and listen the to update themselves. That already forces the AWAR to fallback to its default value, if the selected item disappears.

Following renames is difficult in some cases:

• for trees a rename is copy+delete (requires that the renaming code informs the registry)
• for ptservers it's impossible

For other itemtypes it may be done automatically.

These two concepts (AW_DB_selection and (Tree)AwarRegistry) could indeed be coupled more tightly, as one -callback for the item-container and another one for each item-currently-selected-somewhere would be enough.

Complications will be lists of the "species/name" type vs. the "/tree_xxx" type, and of course recursive notification callbacks in the .

And specials like "protein-alignment lists" or "integer field-names" or …

And … while I'm on the topic of AWAR/future: Are there any reasons why we have to have multiple AWAR databases? If we had only one, the entire "remote awar" thing would no longer be required. It's not clear to the anyway where the "application boundaries" lie: the EDIT4 window appears to be as much as subwindow of ARB_NT as SEARCH_AND_QUERY is. The only place where specific use is made of different awar databases is in EDIT4 with the alignment and sequence-type specific settings (which I doubt anyone but WL understands and uses).

That feature in EDIT4 was requested by other IIRC.

We have property database(s) and (normally) one open database. AWARs are stored in both, because some settings are -specific (like default alignment) or are just fields (like comment) and other settings are -specific and apply to all databases the uses (e.g. color settings, key bindings or behavioral settings).

In theory the property awars of all applications might be stored in one . But that would require to synchronize their values over application boundaries, which either requires

• to use global awars (i.e. use the main to sync local values) or
• to install a second database-server for the property .

The latter has several drawbacks:

• much slower than property ,
  • which works locally w/o socket-comm and
  • which can and does work transaction free (possible because it cannot have clients)
• callback frequency and order will change (due to differences between transaction-based and transaction-free databases). Doing so will introduce interesting possibilities for deadlocks and/or race-conditions between the two databases.

I got a patch here, that implements 'auto-save properties' - might be a good thing to hide application boundaries for less sophisticated ARB .