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].
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.
