On Sat, Jun 16, 2018 at 3:07 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> On Sat, Jun 16, 2018 at 12:46 AM Stephan Beal <sgb...@googlemail.com> > wrote: > >> i will write a longer response when i'm back on the PC, but short version: >> >> - refactoring to a lib is a huge effort. >> ... >> More details upcoming about that first point in the morning. >> > > So... > > http://fossil.wanderinghorse.net/r/libfossil > > that's now effectively defunct, though, as i've been on medical leave for > RSI most of the past 3.5 years and am currently on track to be forced > into early retirement within the next couple of months. > > Stephan, thank you for your thoughtful reply, and your work as well. This is encouraging. I have been on the bench for medical reasons. My sympathy for your condition, I hope for the best outcome in treatment. I'll be reading through the codebase and documentation, some initial thoughts: > Several aspects of fossil make it very tedious (but not difficult, per se) > to port to a library: > > 1) it uses a great deal of global state. That's simple enough to factor > into a Context object, but... > > An incremental refactoring of this into something more modular would be a boon to maintenance and testing. Seems like a sleeping dog we can let lie for now. > 2) it relies on a fail-fast-and-fail-loud allocator. Any allocation error > will immediately (intentionally) crash the app. While that saves literally > half (sometimes more) of code/error checking any place where memory is > allocated (that's a lot of places), that pattern is unusable for libraries. > Granted, allocation errors are rare, but every single C call which > allocates has to check for failure or risk Undefined Behaviour. To simplify > the vast majority of the implementation, Fossil does this checking in a > single place and abort()s the app if an allocation fails. > > Ok, this doesn't sound /ideal/ granted, but maybe not so bad either. I would likely prefer as much allocation as possible during load. An allocation error during this stage is a show-stopper. If it can be refactored into a goto cleanup that doesn't bring the whole tower down, so it just returns a non-zero number unless setup succeeds, that's plenty to get started. > 3) Fossil effectively uses exit() to handle just about any type of > non-allocation error. i.e. there's little library-friendly error handling > in fossil. > > I guess this bullet depends on how much error handling is possible at those points, and how badly failures would bork the global state. If the answer is "none" and "not a bit" then turning some of these exit()s into a library error would be plenty. I suspect it's more like "usually none" and "we don't know because fossil just exits on error". > 4) Last but not least: Fossil implements a great many intricate algorithms > which, if not ported 100% perfectly, could lead to all sorts of Grief, some > of it difficult to track down. Such ports typically require 2x as much > code, sometimes more, because of the addition of error checking and > handling (as opposed to using abort() and exit()). > > libfossil had essentially all of the core-most functionality running > (documented, > too) when RSI knocked me out, and was mainly missing network-related > functionality. It took, according to the timeline, about 16 months to get > it to that point (noting that i also worked on other projects at the time, > so that's not "16 months of effort"). My plan was to pick it back up when > my RSI problems passed, but whether they will is now an open question. In > the mean time, the SHA-related changes have made libfossil incompatible > with fossil, meaning that it would be much more difficult to get it back up > and running. > > The networking-related functionality is the part I personally don't need; we're using the luv bindings to libuv and I'm quite happy with that. The way I explained my desire in that initial email is "everything you can't remove without breaking fossil". From what I gather there are some tasks which rely on the admin interface, and those SQL queries might need to end up in some kind of controller module to make a durable API. This also means you might be closer to done than you think! I concur with Warren that the effort of a libfossil is best justified if it becomes the core of fossil proper. Keeping a libfossil in sync with an upstream fossil poses risks in both directions. There are merges from fossil core, which is an arbitrary amount of ongoing work. There's also the real possibility that libfossil would start innovating in ways that would cause compatibility drift. Tasks like isolating those core intricate algorithms into well-documented modules, where errors and edge cases are handled where they occur, this can really pay off. Merging and patch theory are areas where real conceptual leaps are still happening. This is one of the shortcomings of git: aspects of the data structure are baked into the filesystem-database hybrid, and aspects of the merge algorithm leak into the data structure. Working with a dynamic, relational, single-file database can only improve upon this. The one area of fossil I've done enough reading into to feel comfortable in my understanding is the file format itself. There's an edge to the documentation and I'm kinda peering over that edge slightly. It has the necessary sort of forward compatibility baked into it. Following a SQLite model of using merge_v1, merge_v2, and so on, could really come in handy. i would be thrilled to see someone implement a library for fossil, but > anyone doing so needs to understand, in advance, that it's a large > undertaking. > > I'm happy to sign contribution agreements and otherwise smooth the way to collaborating on this. I am already a project lead on a daunting number of repos; taking point wouldn't be possible, I'm also basically brand new here. A short introduction is probably in order: I'm with Special Circumstances, a nascent think tank. We're contracting with the Defense Department, among other partners, to work on open source software. Our initial brief is concentrated on language-theoretic security; as we grow, hiring people to work on this sort of project is how we intend to do it. Thanks again, Stephan. I'll be looking into those links, please don't feel as though a back-and-forth on each email is necessary, whatever is comfortable for you. cheers, -Sam
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
