Hi, Answer in inline comments, below.
On 07/07/17 09:39, xgid 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! > Yes. That problem will reach us now, but as I understand Sqlite storate will be used only for settings with several advantages, 1) reduced reload time, 2) import/export from/to .leo XML files, which solves the DVCS integration issue, and 3) exploration of improved liveness and responsiveness in Leo. So, concurrency if far away and 2) solves git issues now. > 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!! > No. With import/export issues you can keep XML and versioning friendly format. > 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. > Yes, theoretically. In practice Sqlite over XML have proved better response time in loading and querying when two representation of the same data are available, at least in my experience. > 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? ;-) > Umm.... depends, early optimization is the root of evil, as Knuth said and this is more like a lot of bump that a big hole ;-). > 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. > This is more Pharo/Smalltalk specific. The idea is to pass from native Objects representation to files and then use Git to represent changes in the system. The machinery behind this could be used with other DVCS, but the focus is now on Git: https://github.com/pharo-vcs/iceberg/ > 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? > STON is the storage format you use to "export" notebooks from the image (a snapshot of all objects in your Pharo system) to the file disk, so they can be shared and versioned as usual files, so we use it all the time, for saving notebooks. STON is just plain text and has pretty text exportation options (to include indentation and white space, making it more readable). The diff is provided by fossil over any text file, as usual with other DVCS, so is the combination of STON + Fossil that gives you such pretty and readable output. > I would like to know more of the details: how could I get into them? > A good starting point will be the Grafoscopio Manual: http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/manual.pdf > Thanks in advance, > Xavier Thanks for your interest and proactivity. Cheers, Offray -- 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.
