Hi,
I read all the thread on db-oriented version of Leo. I got lost on
implementation details (what is a shame... :-/), so I'm just want to say
that the things that Alia points here about a single db file containing
all data (external or not) of a project, and collaboration for free is
already possible working with Leo + Fossil without the need to reinvent
fossil, as Edward fears, but just talking more explicitly to it from
Leo. That's what me and my team are doing. It is a newbie
non-programmers approach but is working for us. This is what we do to
collaborate using Leo + Fossil to work collaboratively on a project
called "The Project":
We create a Folder called "TheProject" with the following structure:
TheProject/
|_ theProject.fossil
|_ collaborator1TheProject.leo
|_ collaborator1TheProject.leo
:
|_ collaboratorNTheProject.leo
|_ Folder1/
|_ file1-1.abc
|_ file1-2.xyz
:
|_ file1-n.xyz
|_ Folder2/
|_ ...
:
|_ FolderN/
|_ ...
There is still a lot of shared convention to make this work. The idea is
that TheProject contains .leo files which are _personal views_ of each
collaborator on the data of the project, usually scattered across
external files, which are inside the same folder. theProject.fossil is
the personal repo of each collaborator containing the history of the
collaboration and the files. We don't need to have versions of each
collaborator on external files or on the fossil repo, because putting
this data in conversation is the work of fossil, using a central
repository or in a p2p fashion (if Internet is not working but we have
still Intranet, or at the first stages of a project when there was no
central repository). Each of us works on external data or in leo
personal views as it fits the workflow of everyone and use fossil for
coordination. We abandon, for the moment the idea of shared Leo trees as
shared understanding of a project, but we can see others peoples threes
when we want and use the Nav button to locate the particular info and
see the context of it in the personal view of somebody else. We use
some ideas of GoboLinux about[1] having a personal convention for
organizing the files and symlinked to canonical Gnu/Linux trees.
[1] http://en.wikipedia.org/wiki/GoboLinux
This convention and hierarchy let us to carry the project and its
history in a single Folder, so it can be seen as plain data or as a
fossil repository. There is replication on information, having it in the
fossil repo and in TheProject folder, but having this alternative
approach from the point of view of the repo or the plain files,
justifies this redundancy. Still we have a lot of portability carrying
just one folder and its contents or just carrying the repo.
Now having convention over configuration was our choice, but we imagine
a more automagical world: At first we want to create buttons and
commands inside Leo to all the external operation of fossil, but now
seeing this discussion I imagine further levels of conversation between
fossil and Leo. The idea of a sea of nodes in a Leo database, seems a
lot like the idea of a sea of objects in Smalltalk images. And this idea
of emergence in the sea of data seems more suited for a NoSQL database,
but fortunately Fossil is already a NoSQL database[2], which supports
external files, collaboration and portability.
[2] http://www.sqlite.org/debug1/doc/trunk/www/theory1.wiki
So the question is, how to increase conversation between Fossil and Leo
to solve some of the problems addressed on this thread? My first idea
was to use the DAG[3] support in Fossil to map DAG in Leo, so Fossil
would have kind of special trees which are not for tracking project time
line[4], but Leo trees and the second one was using NoSQL sea of nodes
implemented in the NoSQL fossil database. As I said I have not the
proper knowledge about implementation details, so I will hold this ideas
until a more knowledgeable person tell me more about the implementation
or I have a proper context to play with them.
[3] http://www.sqlite.org/debug1/doc/trunk/www/branching.wiki
[4] http://www.sqlite.org/debug1/timeline
Cheers,
Offray
On 12/26/11 08:19, Alia K wrote:
So, just speculating out loud, let's assume the following:
- the db maintains leo tree state: node content, structure and
versions thereof which are saved by default (until an explicit 'flush'
or 'shrink' command does away with prior or unneeded versions)
- all external files are just rendered views of a particular
(versioned) state of the leo db. i.e. filesystem objects are generated
on demand.
- the leo ui gives the user the option to save, view and edit versions
of leo nodes (and their head + body data)
- the db fulfils the part of @shadow sentinel files
If we are using sqlite, we would therefore get one file (a leo project
file) which carries within it (if unshrunk) a versioned history of all
the changes made to all nodes in terms of content and structure.
If we are using a networked RDBMS (e.g mysql, postgres, sqlserver,
oracle, etc.), we get multi-user leo projects for free (because each
change to the leo node structure is saved on the server and references
a particular user.)
This means that the sql data model for leo projects should be able to
capture all changes by multiple users to all aspects of the project
data and structure.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
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.
