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




On Thu, Jul 10, 2014 at 9:41 AM, Edward K. Ream <[email protected]> wrote:
> 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
>
> --
> 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 [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to