On Tue, Jan 3, 2012 at 4:33 PM, Ville M. Vainio <[email protected]> wrote: > I'd sooner use a ,zip file with the .leo file + external files.
Right. But that doesn't get us a development context that facilitates people's participation in developing db solutions. All that's needed is a db representation and code that gets that in and out of Leo. Then db developers will be empowered to proceed in all sorts of ways, and Edward can ponder how and whether to incorporate the various approaches. Coupled with that process, we get a separation of the db representation from the interface functions that might make Leo something that could be put on any back end that provides for its current reference implementation. That reference implementation does not need to have distribution, collaboration, or versioning. Or concurrent executability, to address Eoin's suggestions. All of those things can all be carefully considered after they've been demonstrated with running code that at least makes the current Leo reference implementation work. (Oops, I did it again.) Seth If I want to zip up the file with its external files, I can always do that. But if my .leo file is > 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. > -- 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.
