I vote for allowing the saving and reading of nodes to a database table, but not attempting to replace simple flat file storage.
Instead, a node attribute could be set to define the secondary storage and/or source. When saving a leo file you should have the option to break the outline nodes from the database (i.e., you only used the database to read-in nodes) or change the stored database node if you made changes, or you could decide to create a new version. And if the attribute fields are set up well you can have the option to reconnect or compare to a stored node. SQLite would probably be the simplest implementation on the user side. A full featured version would allow for any database system using python db interfaces, and include 'cloud' computing. With little doubt, a full-fledged database supported system that uses the system's locking and sharing tools would be safer and richer than allowing nodes in one .leo file to reference nodes in other .leo files. On Dec 15, 10:07 pm, Terry Brown <[email protected]> wrote: > On Thu, 15 Dec 2011 15:49:11 -0800 (PST) > > Dave <[email protected]> wrote: > > I've thought on and off about the merits of a Leo implementation that > > stores its nodes and outlines, not in .leo files, but in an SQL > > database (MySQL, PostgreSQL, SQLite etc). > > There was some work done to get Leo to use ZopeDB as a backend, some > time back. I think it was working at the proof on concept level. > > It's an interesting line of thought. > > Cheers -Terry -- 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.
