I'd sooner use a ,zip file with the .leo file + external files. On Tue, Jan 3, 2012 at 10:58 PM, Seth Johnson <[email protected]> wrote: > 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. >
-- 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.
