I realize my thinking is on a completely lower-level channel from the
thread's current direction, and much of the below is a rehash of my
previous postings, so do skip it if you're busy or truly at a dead-end with
this line of enquiry.
On Saturday, December 24, 2011 5:27:06 AM UTC+7, Eoin wrote:
> "outline structure must be first-class data in shared (cooperative,
distributed) environments."
On Tuesday, December 20, 2011 11:54:24 PM UTC+7, Edward K. Ream wrote:
>
>
> I am no longer sure what the original intention was ;-)
>
Obviously outline structure is already first-class data in any context. My
interest in this thread could be phrased as (perhaps similarly to what the
above was intended to convey?):
Outline structure should in future be as easily shared as external @
> <file> content is today among the members of a distributed work group.
>
AFAIK @shadow files are the only current mechanism that isn't internal to
the .leo file nor implemented as in-content sentinels, which is why from my
user perspective I see them as **an analog** to a way forward - don't let
your greater knowledge of their implementation get in the way. Their key
limitation in this context is that they are "private", which (again AFAIK)
means tied to both the local .leo and the local working copy it's
interacting with. I say it that way, rather than "per user", because
obviously one **can** share these outlines with another local user, but
only serially, not concurrently.
I'm sure the solution is much more complex than I know, but I envision
//something like// @shadow files storing outline information on a "per
tree" basis - from the top-level node down, which I could somehow
"publish", designate as shareable. Rather than storing such "tree objects"
(?) in a relatively opaque, always-need to be connected database, or having
Leo code deal with the complexities of n-way replication/sync'ing these
data, I would think storing them in simple diff-able text files would allow
the workgroup to (continue to) use bazaar/mercurial/git or (as originally
imagined here) Fossil, Leo's implementation of the functionality remaining
independent of that choice.
I believe such a path would also require the nodes themselves (and perhaps
other meta-data?) to be stored externally from the .leo file, independently
of the @ <file>s it's interacting with, and of course my simplistic POV
comes up again with diff-able text files to be managed externally by
whatever distributed VCS. The question comes up as to what remains in the
.leo file itself, an answer to which of course I have no clue other than
the opinion "only that which shouldn't be shared".
My own limited understanding of the issues likely makes this a completely
off-target approach to a solution, especially since the goal I'm positing
may not even be what is under discussion here.
And since I'm probably celebrating Christmas here earlier than most of the
others, let me take the opportunity to wish everyone here a Happy and Merry
one around the world, may next year be a better one than this one was for
all. . .
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/leo-editor/-/bPRxs0LoR0YJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
