Yes I know, this may invite a TL;DR reaction, but I implore you to read on … please.
Please forgive any presumptuousness on my part to even suggest the following. It harks back to the days when the use of handles were the bread and butter when coding on the Mac. It’s probably not necessary to go the full Hungarian these days.
Handles can suffer from performance issues as there’s an extra ‘hop’ to get to the thing you want. It depends on how much of a hit it translates to in the Agenda environment… I’m not sure if there’s a twist on the use of handles with the suggestion, but it could save a major restructuring/refactoring/recoding effort. Here ‘tis:
- In this case, the handle is the global invariant (permalink, UUID, <insert_your_favourite_term>);
- Create a single, global table (OK, database), where each record has two fields, namely a UUID (the handle) and its associated “Agenda-Link”;
- Both fields would quite likely be indexed/keyed, enabling searches for both (this table will hopefully not be referred to as a graveyard);
- Whenever/before an “Agenda-Link” MAC (move/add/change) for a note occurs, look up the graveyard (D’oh! ) for a hit on its current link (I guess there wouldn’t be one if it’s a new note);
- If there is a hit, update its entry with the new one;
- If this is a new note, add a new record with its link, along with a new UUID/permalink value;
- Add a UUID/permalink offering in the “Copy as …” pop up, or better yet …
- Depending on whether people are heavily using the current offering ( direct “Agenda Link” to the note, which goes stale as soon as it moves into another project), you may add a little advisory to the original ”Copy as … Agenda Link” that it may soon be disappearing. This could also happen silently (I prefer surreptitiously), by combining the two or even getting rid of the original as an export;
- You could find out how heavily the current offering is being used (it’s the only one right now), by referring to the global table anyway - distinguishing the lookup by its key (say agenda://note… vs agenda://uuid), although that may break a few things as every instance of the application would need to have its current pointers added to the graveyard;
- Given the immediately above, it would perhaps be easier to (silently) change the “Copy as …” offering to the respective UUID/permalink and treat lookups for “agenda::/note/…” as you currently do, with one extra step. After determining whether the lookup is valid (it may have moved or been deleted) - check whether there’s a hit in the graveyard. If not, add a new record, as described above;
As I said, the presumptuous suggestion would likely not need a major overhaul of how things are presently stored. As to a performance hit, given the application (Agenda) and the use of its links are typically used in an interactive environment, the extra hop may not be that noticeable. I could be wrong.
Aside from obviating a major overhaul, another nice thing about this is the implementation would become more ‘hidden’ in time. And yes, it invites a seamless transition to the user base (important).
I’m sorry if this comes across as being rude in any way. That was never my intention. FYI - I’ve bitten the bullet and purchased DEVONthink, using Agenda for the ‘seagull’ view and DEVON as the detail (the nitty-gritty that move across projects). Using an expensive elephant as a bandaid is not my idea of fun. I prefer Agenda’s more ‘intimate/personal’ nature, but it currently doesn’t work (for me).
I wonder how many find really good value in the current “Copy as … Agenda Link” offering(?). I personally can’t imagine there being a huge fan base.