On Tue, Jan 3, 2012 at 3:48 PM, Seth Johnson <[email protected]> wrote: > 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.
And why not, for the @file business, keep those saving to the local standard file system: just put the .leo file in the db for now. In the routine for saving, have a flag that once it's set, will save the .leo file in the db, as well as save it in the traditional fiel system -- or one or the other. I don't see why we have to start by solving distributed, collaborative work on the @file stuff, with versioning. Just save the .leo file. Let people suggest different approaches starting from there. (Getting redundant, sorry. I'm done. :-) ) 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.
