On Sat, Dec 17, 2011 at 2:11 PM, Ville M. Vainio <[email protected]> wrote: > Googling for leoqviewer gets you to github repo. I may push this to contrib > branch if needed.
Thanks for this. Rebecca is a great listener. I was chatting away this morning at breakfast, saying the following: 1. The only way to scale up Leo so that it could, for example, handle data sets like the human genome project would be to store Leo's nodes in a DB. In such a situation, Leo files become "windows" or "views" on the DB. Rebecca correctly points out that an individual Leo file can contain multiple views of data, and this quality does not change if the nodes are stored in the DB. 2. Basing nodes on a DB has the potential to allow cross-file clones: the DB (potentially) can solve all the worrisome problems with multiple access. This has the potential to be a game changer as far as the *idea* of clones, nodes and views is concerned. I don't know how this will work out, but just about every Leonista, including me, has wanted more capable (cross-file) clones. 3. The interaction between bzr and a DB is intriguing. Perhaps we will indeed use fossil, which I am just reminded is based on SQlite. In short, I believe that this year will see a grand re-visioning of what Leo is and can be. This new vision has arisen more from the usual suspects than from me--a development that pleases me greatly. Ville, your code is an important step forward. I'll commit it in some form soon, and begin serious study of it as a way of priming the subconscious pump. Great things will come of this, I am sure. Edward -- 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.
