Xavier, Well, discussion shows that we're agree about the worthiness of this exploration. I think that Sqlite limitations you mention will be far to reach compared with XML limitations, which are now starting to show now, like reloading settings time. I would try to take this first step forward and after that, extend exploration to other fronts, like any database or DVCS. Concrete steps and after that proper abstraction would be my approach. Something similar is happening in the Pharo community, adding closer integration with Git, and after that abstracting to others (Fossil, Mercurial).
Unfortunately my expertise is far away from Leo and Python these days and closer to Grafoscopio and Pharo, but I try to keep an eye on the list and, at least, comment on possibilities and approaches. Cheers, Offray On 06/07/17 19:31, Xavier G. Domingo wrote: > >> Ville on this counts with my "moral" support (because my technical >> capability is departing from Leo and Python to Grafoscopio and Pharo) >> and this is a worthy exploration. Advocating for a simpler Leo format >> has been in this forum since several years ago (YAML, JSON, etc have >> been in our proposals and also closer integration with Fossil to >> resolve external files). Sqlite format is now about improving reload >> times, which can sum to explorations on liveness of the environment. >> At some point this is about which core assumptions can be reevaluated >> (like XML as storage medium), with some practical prototypes to see >> the implications. This has been pretty valuable in my case, I even >> reevaluate the programming language and development environment. Of >> course as a community, Leo doesn't need to go that far away, but this >> is an exploration that many have been waiting for. >> >> Xavier, I strongly recommend you and others the video about Sqlite as >> an storage format [1], that has been pretty inspirational about >> alternatives about where "masses wisdom" is going (Sqlite instead of >> XML, Fossil instead of Git / GitHub) and the opportunities this >> almost uncharted territory opens. >> >> [1] https://www.youtube.com/watch?v=8y_ABXwYtuc >> >> Cheers, >> >> Offray > > Thanks Offray for your comments and the video. I'll try to get time to > see it (an hour is a lot of time for me at present), but let me tell > you that I'm already aware of the strenghts of Sqlite as storage > format: I've been using it for over 14 years now. We even use it at > work in production environments! So guess what: I also know its > limitations(1). > > And I'm also going to tell you a secret, but don't tell anybody: I > have also used Fossil for some time. And even with Leo! thanks to a > great experiment shared by vitalije some time ago > <https://groups.google.com/d/msg/leo-editor/19288wA3aKA/P5rjfnADAgAJ> > which I passionately tested for a while. > > But the "problem" is not Sqlite. Nor it is the "final solution". It > can be a good step forward, so *I really support the work that is > being done and the new possibilities it opens.* What I'm suggesting is > that we should try to take advantage of this work to make the right > architectural changes to Leo so it can easily handle *any**storage > backend*. In the same way that Edward has shown that the current Leo > core design is solid enough so it can easily *use **nearly any > GUI**above it.* Because now it is Sqlite, but in the future it can be > some other format. We just need the proper abstraction layer. > > In the same way, I think we should try to have an abstraction layer > from the underlying SCM, so it can be git or Fossil now, but any other > in the future. *I wish Leo a long live!! * > * > **(1) Regarding Sqlite limitations:* > One of the problems is its efficiency in multi-threaded or > multi-process concurrent write access environments. But the question > that concerns me the most at this moment is the one related with the > possibility of having clean diffs of the outline changes and merge > capabilities using any SCM. *But in this point you are the expert > <https://groups.google.com/d/msg/leo-editor/19288wA3aKA/upGHE1K_AQAJ>!* > So I wish you are going to help us in finding the best solution. > > These are really exciting times, as Terry recently told! And this is a > great team! > Xavier > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. -- 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
