I agree that this vision is a inspiring! Probably obvious to y'all, but I would also suggest building a plugin architecture for data storage first, so it would be easier to switch from SQLite to Oracle or whatever down the road.
Such a model should also allow Leo to treat a given outline/clone organizational model - a given "view" - as a unit, so you could load/unload different views as needed, simplifying navigation and helping to keep intact the overall "shape" offered by that view, without the current requirement of having multiple trees for different purposes being visible at the same time. And store the views themselves in the database so they're easily shared - definitely would need version-control if these weren't just read-only for the other users. . . However (back to basics), **please** don't add "database programmer/administrator" to the requirements of using Leo for basic functionality - keep storage of plain text in filesystems as the base/core data model, and the database layer as extended, optional flexibility. This process could also I imagine enable more flexibility in thinking even about the plain text in filesystems storage model - from a recent conversation with Terry<https://groups.google.com/d/msg/leo-editor/xf6_HBxlV_c/p9E72lFHM8cJ> : > > Fundamentally Leo stores data in XML. It's always going to be possible to get data back out of a .leo file without Leo, although it might require tools / skills somewhat different from plain text. But storing a tree with clones in plain text would make the plain text so sentinel heavy it might as well be XML... > Yes, but the beauty of the @shadow structure is, "who cares"? The only people that are going to look at the sentinels are programmers who care about Leo. Therefore sentinels in @shadow files can carry all the important data right out in the filesystem. ------------ Sidenote as a cautionary example of project evolution, skip if you're busy: One of my favorite platforms for ad-hoc text-information management, and a brilliant tool for presenting structured views complex data is TiddlyWiki, whose basic value proposition (IMO) is allowing the functionality of a full interactive website in a single HTML+javascript file. A few years ago most of the more tech-savvy members of that community, including the core developer, started focussing a lot of time and attention on various different "external data access" implementations for all the same reasons as this discussion, and IMO this has led to the core code stagnating, to the point where one must use old versions of Firefox or IE to use the tool. BTW apparently this will change as the project's founder is developing a new version, apparently starting from scratch (uh oh?). All this is IMHO of course, and I still just love TiddlyWiki. . . On Friday, December 16, 2011 7:32:04 AM UTC+7, HansBKK wrote: > > > I think it would have the same sort of dangerous complexity as the > concurrent development of full human cloning and mass time-travel tourism. > > But I suppose both are inevitable anyway. . . > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/lJgpTmhsKqEJ. 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.
