On Tue, Jan 3, 2012 at 3:20 PM, Ville M. Vainio <[email protected]> wrote: > On Tue, Jan 3, 2012 at 6:41 PM, Terry Brown <[email protected]> wrote: > >> I think that's the case. @<file> handling is complex, I'm not sure how >> familiar with it Ville is, I've poked around the edges a bit, but don't >> know how it would interact with loading to / from a DB. > > My code just dumps everything, including under @<file> stuff, to db. > > This is by design, as I want to ship .leoq as a standalone file that > you can send to your phone in email, or whatever. > > Not writing @file nodes is easy, just stop traversal when you see one. > Likewise, reading back in is easy, just expand the whole tree and > after that do the @file node handling for the whole tree. > >> And even if that wasn't an issue, the next step beyond using a DB to >> replace the file system would also be complex, whether it was sharing >> or whatever. Well, perhaps versioning wouldn't be so hard, but >> sharing is certainly challenging. > > I think it's best to left advanced use cases like that unhandled. Even > if coding it wasn't too hard (it probably is ;-), people want simple > and reliable workflows for their creative work, users are paranoid > about losing data if they can't completely understand what is > happening under the hood (e.g. clone wars must have spooked of many of > us)
I think we should leave everything new unhandled. Just regard the db as a file system you're saving your own Leo files into. The only new thing should be, instead of just saving it as one file as a whole, store the elements as separate units (records, nodes, whatever), but just make sure that you have a save and load procedure for that db representation, that works because all it does is save your file in that form and load it. Then everything current in Leo will just work. Plus people would know what they need to store in the db representation, and what they need to feed to the load procedure. They can use that and hack at different ideas, just knowing that at bottom the classic, basic Leo is still going to work so long as they represent it equivalently to that reference representation, and feed the load procedure with what it needs. Seth -- 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.
