On Monday, December 19, 2011 11:59:12 PM UTC+7, Edward K. Ream wrote: > This post is pure speculation: the vision may turn out to be a mirage. It's also long. Feel free to ignore.
> Otoh, the ideas here are completely new, and exist in a new design space. Reading this fired off so many synapses, generated so much dopamine etc., was as enjoyable to me as sex or quality chocolate. And that without even understanding most of the implementation side, just imagining that you consider such things possible. . . And you know already I hardly have a clue what I'm talking about here, completely unable to respond at the same level of abstraction and likely just flat out wrong, so of course feel free to ignore, but sometimes with blue-sky thinking ignorance can be an advantage 8-) > 2. To coordinate *distributed* Leonine db's without rewriting fossil or bzr or sqlite ;-) > Point 2 seems to be the biggest challenge. By "db" do you mean the underlying database engine (eg sqlite?). IOWs what needs to be distributed? Syncronizing multiple database servers would indeed be IMO overly complex. To me, the fundamental unit that provides the necessary simplicity is the node. In an always-connected model the server acts as the centralized coordinating storage mechanism to avoid conflicts. That doesn't seem to me to be what we're after here, we want to allow data mods by disconnected users to be synchronized back to the "center" which in these modern distributed systems is just a concept, implementation details determined by the SOP/workflow as defined by a given work group. To effectively leverage Fossil (or whatever) VCS as a data store without having to write your own, it seems to me that both the nodes and the "views" need to be stored out in the filesystem in a standardized way, most likely each node being a separate file. I could see "view files" as representing each tree defined by the "top-level nodes" - that would allow me to pull in or drop a given tree from my current "collection" as needed. Obviously this is completely separate from the @ <file> mechanism, which is IMO just the export mechanism at a much higher level, after "assembly" by the "view", or import when dealing with the non-Leo world. So to my mind (admittedly limited), if we're really focused on the distributed side, why not just stick with the filesystem as storage model - isn't it the database that's complicating the picture vis-à-vis the VCS? And if the goal is to be able to work with a given distributed VCS without customizing it, the why not set a goal of being able to work with any of them? Then the group can choose to work with whatever distributed VCS they like, and you don't have to rewrite big chunks of code to accommodate the shifting sands of that domain. It also forces the simplicity mandate - if your new model of data storage is a simply a collection of plain-text diff-able files in folders, at that level they all **are** automatically interoperable. -- 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/-/uoNFziZYT98J. 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.
