i will write a longer response when i'm back on the PC, but short version: - refactoring to a lib is a huge effort.
- up until late 2014 i was actively working on a library port and had most of the core features working. - RSI struck me down and has since effectively removed me from the programming world, so libfossil has remained unmaintained and is not longer compatible since the addition of non-SHA1 hashes (and i have no estimate for what it would take to bring it up to date). More details upcoming about that first point in the morning. ----- stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Fri, Jun 15, 2018, 22:26 Sam Putman <atmanis...@gmail.com> wrote: > First post. Hi! > > I've been lurking along, following the discussion here. > > Common thread is a desire for 'more fossil'. I'm in this camp myself. > > But I see the attraction of the core fossil application. It works perfectly > for a fairly close-knit community, and it follows a philosophy that's been > working for decades now. One that is, if anything, more effective as it > becomes less fashionable. > > Let me make a suggestion: what we need is not more fossil, it is less > fossil. > > I wrote Dr. Richard Hipp about this earlier, his response was positive > enough > that I felt encouraged to bring it to the community. > > For my own projects, I've switched to fossil. It's the obvious choice, > we're > using SQLite in preference to the old pile o' files already. > > The fossil codebase has all the core algorithms for storing deltas in a > single database file, merging, deduplication, Merkle hashing, key signature > management, extensible metadata... I don't have to sell you on the virtues > of this VCS! > > I would benefit greatly from being able to use this excellent collection of > SQLite best practices and algorithms, the same way I use SQLite: as a > static > or linked library, one which can be wrapped in various FFIs for VMs, or > linked > directly from a systems language. > > My own case would call this from LuaJIT, what matters is everyone can be > happy. fossil proper can stay attuned to the SQLite/Tcl/Tk alliance, as it > should, and adventurers could wire it to mailing lists, wikis, forums. > > I think this would help fossil really stand out. Just the fact that here > we > have tools to read and write git to a single-file database, that's huge! > > Tools for revision control would be a real boon to applications already > using > SQLite as an AFF. I could go on. > > I always feel some trepidation towards what amounts to asking other people > for > free work. I feel this refactoring could benefit fossil as well as my own > software. I'd be a part of such an effort as soon as anything halfway > plausible > was compiling, if invited. > > Sincerely, > > -Sam Putman > -- > Special Circumstances > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
