Persistent gnx's (and uA's) in foreign files without DB's

[Edward K. Ream]

The recent discussions of SQLAlchemy, http://www.sqlalchemy.org/ and camlistore, https://camlistore.org/ have been fascinating.  Both look like excellent projects that may have important benefits to Leo.

Here, however, I'll explain why it looks to me like no db of any kind can possibly solve the fundamental problem of reliably associating gnx's (or equivalently uA's) with nodes in **foreign files**, that is, nodes created by @auto, @org-mode or @vim-outline trees.

The essence of the problem is easily stated.  We assume (as part of the meaning of @auto, @org-mode or @vim-outline trees) that people who do **not** use Leo will modify such foreign files.  If this were not so, we could just use @file and have no problems at all recreating gnx's, clone links and uA's. There seems to be **no way** to update any db (of whatever kind, local or global, and regardless of the keys used) when non-Leonine users modify the file.

In particular, Fidel mentioned some scheme of "tracking" changes to nodes. That will work when we Leo users modify the file, but how could such scheme possibly track changes when non-Leonine users modify the file?

Instead, it looks like we must accept the possibility that changes to a foreign file will modify a node in ways that will break *any* possible bookmark (or key) to the node.  That can't be helped.  The recent posts about bookmark clones suggest workarounds, namely that bookmark node will remain uncloned.  Not exactly the end of the world.

In short, I see no way to track changes to nodes made by people who do not use Leo.  Given that fundamental fact, it seems that bookmarks are the way to go.  We'll want to create flexible ways of connecting bookmarks to nodes, but we must accept the fact that bookmark nodes might remain unconnected (uncloned).

Your comments, please.

Edward

[Kent Tenney]

That's all I need to hear.

I'll see what kind of scaffolding I can come
up with. I think that's a better way to go, my interests lie outside what
is Leo core's responsibility, and I'd probably end up complaining about
it anyway.

(-;

I just didn't want to do work which would become obsolete when Leo
replicated it in core.

Thanks,
Kent

> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+...@googlegroups.com.
> To post to this group, send email to leo-e...@googlegroups.com.
> Visit this group at http://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.