Hi Tim, Pierce, No problem, I was going to ask about Fossil as well, I know it is a self contained SCM, with issue tracker, and whatnot. People that uses it don't want to use git except if forced to. So I also ask how this would work. :)
I saw SQLite-sync before, but it is a commercial product, and its platform support/setup seems convoluted. dqlite might be a viable alternative, from more than reliable provider, it's is not clear whether I have to use a different library to access SQLite (it seems so) or a special wire protocol/api calls. The only drawback I see is that, according to the the FAQ [1], from the CAP theorem the consensus algorithm puts Consistency and Partition and leaves out Availability. I'm looking into CouchDB and reading its "Definitive Guide"[2] book. It seems straightforward to install, distribute and uses a MVCC approach that puts availability as its top priority, and since my domain data has a low probability of conflicts, the eventual consistency will be more than enough. OTOH I'm not used to document based DBMS, which will require me to rethink a lot of my domain and application models. Also, it has a simple HTTP API (JSON/REST) and there is an existing Smalltalk client that might be ported and adapted to Pharo https://cwiki.apache.org/confluence/display/COUCHDB/Smalltalk Background: I have the prospect to develop an application to replace an existing one that is a desktop app that "syncs" from/to a central server every 15', most of the data entry happens locally and the central server is read only for the most part, it is old, ugly, but it works "reliably", so I must come with an alternative that is as reliable as that, and then provide a better UI/UX, new features, etc. Regards! Esteban A. Maringolo [1] From https://github.com/CanonicalLtd/go-dqlite/ Q: When not enough nodes are available, are writes hung until consensus? A: Yes, however there's a (configurable) timeout. This is a consequence of Raft sitting in the CP spectrum of the CAP theorem: in case of a network partition it chooses consistency and sacrifices availability. [2] http://guide.couchdb.org/draft/index.html El mar., 19 feb. 2019 a las 10:03, Tim Mackinnon (<tim@testit.works>) escribió: > > When you say Fossil - are you referring to > "https://fossil-scm.org/index.html/doc/trunk/www/index.wiki” ? > > I’ve seen it come up a few times - is it good? But rather than subvert > Esteban’s thread - if it is the above, can you hook into it to save > application runtime artefacts such that a distributed application can read > them back (I’d just sort of assumed it was for saving code and docs) - but it > sounds like it can go a bit deeper than that (which seems quite interesting > and perhaps what Esteban is after?) > > Tim > > > > On 19 Feb 2019, at 01:46, Pierce Ng <pie...@samadhiweb.com> wrote: > > > > On Mon, Feb 18, 2019 at 02:56:10PM -0300, Esteban Maringolo wrote: > >> I have the requirement that an app that I'm prospecting must be able > >> to work offline and synchronize changes once the connection is > >> restored. > >> > >> I want to avoid having to write "sync" logic manually. > > > > I've not done this for real before, but here are some possibilities: > > > > - https://github.com/sqlite-sync/SQLite-sync.com > > - http://www.symmetricds.org/ > > - https://github.com/CanonicalLtd/dqlite > > - Use Fossil as your database > > > > > > > >
