On Mon, Feb 9, 2015 at 12:56 PM, Vikrant Chaudhary <vikr...@webstream.io> wrote:
> * No global repository object: At present, reference (henceforth > "object") to the repository is stored in a global variable "g". I > think that in sqlite3, a process can simultaneously handle connections > to multiple databases because for every connection there is a "struct > sqlite3" object, but that is not the case with Fossil. It would be > That's what libfossil is largely about - refactoring fossil to use that approach. http://fossil.wanderinghorse.net/r/libfossil/ > great if Fossil could also simultaneously hold references to multiple > repositories, say using "struct fossil2" object, passed as an argument > to all functions which need it (à la sqlite3). Right now, to > circumvent this, in Ruby I'm planning to wrap all fossil calls in a > mutex which reassigns "g" to current repository's Global struct. > i can say from experience (with libfossil) that such a re"struct"uring is a really big effort, and is not feasible within the current code basis. For a v2 rewrite, it could be done, but doing it within v1 would be time-consuming and risky (in terms of regressions). i'd be all for it, but would recommend against using the current code basis for it. > * C API: Along-with/instead-of a JSON API, expose a C API like sqlite3 > (the above point should automatically do this), which then can be > consumed and transformed in whatever format - be it JSON, MessagePack, > XML, Protocol Buffers etc. For serving HTML through CGI, Fossil itself > can consume its own C API, and produce HTML via TH1 templates (à la > MVC architecture). > A library-style API inherently takes it in this direction. As part of libfossil i've developed two independent script bindings, mainly to ensure that the library API is capable of such separation. * No exit() calls?: "fossil_fatal()" terminates the process which is > not good when Fossil is dynamically linked. It would be great if I > could convert fossil_fatal() to an exception in my Ruby bindings. > Maybe fossil_fatal() should call a registered callback and exit() only > if no callback is available? (I noticed that sqlite3.c never calls > exit(), how does it handle fatal errors?) > fossil was designed from the ground up as a monolithic application, which is where its usage of exit() (and abort()?) comes from. It has history "failed-fast" for any notable error. That's also part of what libfossil is about - a library conventionally has no exit() calls. > * SQLite like C amalgamation: If it isn't very hard to do. Just like > sqlite3, separated in 5 files: fossil-shell.c, fossil.h, fossil.c, > sqlite3.h, sqlite3.c > *cough* http://fossil.wanderinghorse.net/r/libfossil/wiki?name=AmalgamationBuild :) * Single command to clone/init and open: I propose "--open". Doing > "fossil clone --open https://example.org/foo"; creates a directory > +1 > * Distributed Pull Requests: Just like Github. Say, if I have a > Richard recently added related (but not identical) support for so-called drive-by-patches. Haven't tried it yet - no programming for me since mid December :/. In other news: my elbow underwent a 90% improvement literally overnight on Saturday. My fingers are still numb, but i can live with that as long as my elbow allows me to type. Still don't know where my current limit is on typing, but will be experimenting (with mails like this!) to find out before the next doctor's appointment on Thursday :). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-dev mailing list fossil-dev@lists.fossil-scm.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev
