If the question is "the others and the Leo way" a partial solution can belowering the requirements to interface with Leo. This can be done by the use of different interface paradigm, as the use of 9P or Styx and DBUS.
Il giorno domenica 31 marzo 2013 05:28:22 UTC+2, Terry ha scritto: > > On Sat, 30 Mar 2013 14:56:55 -0700 (PDT) > "Edward K. Ream" <[email protected] <javascript:>> wrote: > > > So let's refocus on the future of Leo. What problems with Leo (or .leo > > files) would DB's be likely to solve? This would be a good topic to > > discuss at the sprint. Your comments, please. > [..] > Leo's data storage needs are very simple, a list of nodes, a list of > edges. DBs are one very easy way to get networked storage, and they > also offer opportunities for versioning. git is another networked out > of the box data store that might work. I think DB's relevance to Leo > are networking and versioning, not table relating and querying. > > I don't think this line of thought is about fixing Leo - it's ability > to load and save data locally's fine, apart from multi-outline save > speed, and that's not a huge issue. So this is about new capabilities, > networked, possibly collaborative data, etc. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
