On Mon, Jan 2, 2012 at 4:04 PM, Offray Vladimir Luna Cárdenas <[email protected]> wrote: > Hi, > > I read all the thread on db-oriented version of Leo. I got lost on > implementation details (what is a shame... :-/),
I think the single thing that will best get db-oriented Leo going will be someone just writing code that stores complete Leo files in a database of any kind at all. Code to put that database into the outline interface app would complete the picture for lots of people to start providing running code that does collaboration and versioning. That would, for instance, make it easy for you or Alia to demonstrate what Fossil can do. Maybe the thing to do is to think in terms of a "reference implementation" of the basic, non-collaborative and non-versioning classic Leo, and embrace the notion that many backends could be developed for it. That "reference implementation" could add functions for collab or versioning once someone has shown how it could be done. Different approaches would likely have different characteristics -- something that is designed for concurrent execution a la Rich Hickey concepts will behave differently from other approaches, but we'd see the implications of each approach while each solution would have to at least meet the reference implementation requirements before we'd see it as "mature." I think your post was easily the most constructive one in this entire thread. Seth > 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.
