On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado <dipto...@gmail.com> wrote:
> Converting Fossil into a library has a lot of downsides: > > - Building a library in a platform-independent manner is non-trivial > (unless making use of things such as libtool or CMake is alright). > It can't be any more problematic than making a portable binary. The majority of fossil's portability-related problems have been in app-level code on Windows (e.g. converting paths from UTF8 to whatever Windows uses). > - A lot of additional code has to be added to avoid being tricked by > users passing incorrect parameters. > That's just part of - a library has to be more careful with its parameters AND must also report problems instead of just dying immediately. > > - Testing is more tedious; test code needs to be developed in C to > ensure the calls work. Not if we script it. sqlite3 runs all its tests in TCL, and it is arguably the single best-tested open source library in the world. > Unless the test code can be generated > automatically through a scripting language, which is not simple > either. > Once a library interface is in place, adding a script binding is, as a general rule, very simple. i've bound literally dozens of 3rd-party APIs to 3 different JS interpreters, and the process is more or less always the same. > - Ensuring API/ABI compatibility is harder. And this actually slows > down development because new features have to be implemented > i don't envision us having to work about this. Fossil is not a library with the same uses as, say, sqlite3. If we have to concern ourselves with this level of compatibility then fossil has probably gotten more popular than i expected. In any case, i do not envision most people using the library - they will have a single binary (built on top of the library). The library would be there so that fossil can finally be integrated into places like IDEs. > - Sooner or later, a useful library has to match the following > requirements: > > * Re-entrant > * Thread-safe > * Support both synchronous and asynchronous remote operations > * Friendly to bindings > Thread-safety is not a factor here, i think. Any given instance of a Fossil context only need be single-threaded (all of the multi-threaded use cases go out of the project's scope, i think, e.g. parallel threads for searching). The is, IMO, no reason why fossil would need to support multiple threads. Reentrace is, in my experience, not a problem so long as one uses a Context parameter. Asynchronous operations are another place which i consider to be out of scope for fossil. Being friendly to bindings will be a focus of mine - i've got a considerable amount of experience in this area. > To match the previous requirements, designs can be come very > baroque, and therefore, harder to read and maintain. > True, but fossil's current code is monolithic and relatively inflexible in the face of change. > - A thorough documentation would be necessary. > Not a problem - both Richard and i are documentation maniacs. My one-man open source projects are regularly rated in the top 10% most-documented projects by ohloh.net :). Writing technical docs is a hobby/paste-time of mine: https://docs.google.com/presentation/d/1plJbtQZXKBymEiw9sYy9xqnzMleWuYO461R3VrocOWQ/view > > But, the worst of all You say that as if writing docs is a bad thing ;) > , is that even if the library is greande-proof, you > would be indirectly hit by bugs in external software using it. > That's just part of it. Right now we're in the situation that fossil cannot fit in places it should be able to fit (e.g. SCM support in IDEs) because it is monolithic. > Even Git, with its humongous manpower, has struggled a couple of years > to make an incomplete library. > Git has a level of popularity/penetration which (i hope!) never plagues fossil. As long as fossil stays niche-market, the dev team will have a lot more freedom in the form of a _lack_ of pressure to conform to requirements of popular plugins/add-ons. > > I'd suggest the Mercurial approach: focus on the JSON API and offer it > over multiple transports (HTTP, SSH, UNIX sockets, pipes). Actually, that's kind of how the JSON API was started. Richard asked, "what does Fossil need?" to which i answered, "a library." After agreeing that the effort would be huge, i settled for JSON (which is, in effect, a network-linked DLL). However, some of fossil's primary features cannot fit into JSON without significant shoe-horning. e.g. commits may require binary data, for which there is no JSON equivalent. > Then let > anybody interested on integrating develop a client in their language of > choice. Because JSON has first-class support in almost any computer > language, bindings would not be necessary and the current process model > could be kept. > the JSON API can, in principal, proxy most of fossil's operations. There are a handful of things (namely binary data) which is cannot do. Another potential pain point is JSON (despite common misconception) does NOT specify an integer precision, which means that any large integers it generates might or might not be portable to other systems. This can be worked around by using doubles instead of integers, and we have not _yet_ seen such incompatibilities, but i expect to at some point. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
