Here is my wishlist for 2.0. I'm currently working on an open-source Ruby wrapper for Fossil using SWIG. I'm a newbie in C, so I can be wrong about my assumptions on Fossil codebase. Please correct me if that is the case.
* Support for plugins: Either through a registry (like Mercurial and Bazaar) or command invocation (e.g., "fossil foo" executes fossil-foo found in PATH). * 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 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. * Separation of concerns: (Also echoed by Baruch & Stephan) Let's not mix in presentation and logic in source code. For e.g., there is no clear C API to work with wiki pages, and for now I need to emulate a CGI request and sometimes extract data from HTML. We have TH1, let's use it more (no HTML in C). * 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). * 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?) * 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 * Single command to clone/init and open: I propose "--open". Doing "fossil clone --open https://example.org/foo"; creates a directory "./foo", clones the repository in "./foo/.fslckout/repository" file and then opens it in "./foo" directory with checkout database at "./foo/.fslckout/checkout". This should make users of other DVCS feel familiar when they are being introduced to Fossil. I proposed ".fslckout" instead of ".fossil" because we already reserve the ".fslckout" name in root directory (not sure about ".fossil"). * Distributed Pull Requests: Just like Github. Say, if I have a fossil-scm.org clone at https://example.org/fossil, and I have some changes that I want to get reviewed and be merged upstream. I can create a new new ticket at fossil-scm.org, and specify foo@https://example.org/fossil (branch@repository) as source of my PR. In background fossil fetches the necessary changesets and creates a nice diff of changes that can be merged with just a click. Thoughts? Cheers. - Vikrant On 5 February 2015 at 16:19, Stephan Beal <sgb...@googlemail.com> wrote: > On Thu, Feb 5, 2015 at 11:45 AM, Stephan Beal <sgb...@googlemail.com> wrote: >> >> Summary: since mid-December, and for the foreseeable future, i'm on >> medical leave due to nerve damage in my left elbow caused by too much typing >> (too-long sessions over too-long a period). It's unknown when/if i will be >> able to type any significant amount at a time, or hack, again - there has >> been no improvement in that time :/. >> >> That said, i'm always available for moral support ;). > > > FWIW, short summary of what libfossil is missing right now: > > - merge algo needs porting > > - 'update' depends on merge > > - all pieces for 'checkout' are in place and working, but the checkout > itself is not yet implemented. > > - anything network-related: that is waiting on 'update' and the intent is to > model it as an abstract stream consumer/emitter API, as opposed to > "network". The stream interfaces are in place and used in a couple places > (e.g. diff (_not_ fossil delta) generation is streamed in libfossil). > > > > -- > ----- 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 > _______________________________________________ fossil-dev mailing list fossil-dev@lists.fossil-scm.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev
