On Fri, 7 Jul 2017 07:39:20 -0700 (PDT) xgid <[email protected]> wrote:
> > Well, discussion shows that we're agree about the worthiness of > > this exploration. > > Yes, we do! > > > I think that Sqlite limitations you mention will be far to reach > > compared with XML limitations > > I don't agree. The concurrency problems will, but the problems to > have Sqlite files under git are here right now > <https://stackoverflow.com/a/551409/5104752>: > > *In short, you’ll probably be unhappy trying to keep a database > versioned > > using a source control system.* > > ...unless you use Fossil as VCS, of course! > > But then, *we all have to have clear in our minds *that using Sqlite > as the next Leo file format *is forcing us to take those files out of > git, or to use Fossil* as VCS. Yes or yes. And those are important > facts!! I'm not sure but I suspect your emphasis is intended to be humorous. Or at least to underscore an important point by coming at it sideways :-) I don't think we've considered the impact of switching to a binary format, and that currently it's a major unresolved question for the sqlite initiative. While I've used sqlite / SQL and am comfortable with them, I don't think XML is a significant negative for Leo. It's always a mistake to read or write any format, XML, JSON, YAML, etc., without using a library. And if you use a library, all their intricacies are taken care of. XML isn't slowing Leo down. The leosax module in leo/external/leosax.py can read Leo outlines (without external files, but settings don't use external files) into dict/list structures in a fraction of the time Leo takes to fully load an outline, it's all the other clever stuff Leo does that takes time. I think there's great potential for simplifying init. code and settings editing by using something simpler than full blown Leo outlines for the key/value store needed for settings. Sqlite is certainly an option - if you're just using it for settings, it may not be necessary to include those files in VCS. > XML limitations, which are now starting to show now, like reloading > > settings time. > > I insist: reloading settings time in Leo is not a limitation of its > XML file format! As I have already tried to explain, that is a > separate problem which can be solved by its own and which should be > independent of the backend used as storage. I agree. The fact that c.config.getInt('bookmarks-levels', 1) is now returning 3 instead of 1 doesn't mean the bookmarks plugin suddenly starts displaying 3 lines instead of 1, that needs signals and redraws etc. etc. Whether changing the setting changes the behavior or not depends on implementation - it could be sufficient to change the setting, but often isn't. To create more room for confusion :-} there's also now discussion of more dynamic *code* reloading. I'm unclear as to whether this is for Leo only, in which case it seems primarily a benefit to Leo developers, or if it would cover other code being developed in Leo. Without any standard way of doing the latter, I'm not sure how that would work. Cheers -Terry > 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. > > I agree in that exploration or prototyping is a good way to go > forward, but well... problem anticipation is also a great tool! It > can help you save a lot of time or even avoid some crashes. Shouldn't > I warn you if I know there's a big hole in the road some meters in > front of you? ;-) > > Something similar is happening in the Pharo community, adding closer > > integration with Git, and after that abstracting to others (Fossil, > > Mercurial). > > Good to know. At the end we all are trying to solve the same > problems! Do you already have a common API to interact with them? > Please share with us whatever you have on that side. > > But again: I would separate the VCS integration question from the Leo > storage format. They are different issues which deserve deep analysis > and design on they own. > > > 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 > > Yes please! I really would like to understand how did you did to have > this nice diff > <http://mutabit.com/repos.fossil/panama-papers/fdiff?sbs=1&v1=255e79b046584a36&v2=cbfe8929edf64212> > > for your outlines in Grafoscopio! At which moment do you use the STON > format? Is it just before making the diff? > > I would like to know more of the details: how could I get into them? > > Thanks in advance, > 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.
