On Tue, Jul 23, 2013 at 4:30 AM, Joseph R. Justice <jayare...@gmail.com>wrote:
> ...Some random thoughts on Fossil v2 as a library (call it "libfossil2") > and as a default client / server binary which makes use of the library > (call it "fossil2client" or "fossil2scm", I seem to have used both names), > which I realize you might already know about or have thought of but just in > case... (if only because I have a terminal case of Male Answer Syndrome) > (and, wow, this got longer than I expected, and I apologize in advance for > telling you in detail all about everything you Probably Already Knew and > moreover Knew Far More About Than I Do...): > Rabid rants are in no way excluded from participation, provided they remain polite ;). > * Fossil2client should *not* expect or require libfossil2 to be compiled > into it statically, or have an embedded copy of the source for libfossil2 > within the source of fossil2client. > Right. My goal here is a normal library/client relationship. Static linking is an important option for fossil (because it's popular with users) but is not a requirement. > Debian, which is the Linux distro I am most familiar with, already does > this (or appears to anyway) with fossil v1, see > http://packages.debian.org/jessie/fossil where the fossil binary depends > on libsqlite3-0 (>= 3.7.11 at this instant). I don't know if fossil v1 > ships with an embedded code copy of sqlite (I haven't looked), > Strange. Yes, fossil embeds its own. That dependency was probably automatically determined by a script which looks for common symbol names in the resulting binary. > but if it does they're stripping it in favor of sqlite as an independent > library object and making their binary for fossil v1 dependent on that > independent sqlite library object. > i suspect it's only a bookkeeping error, and that (ld fossil) on that system will reveal that it does not link against /usr/lib/libsqlite3.so > I fully expect they would / will do the same with fossil2scm as a > dependency of libfossil2. > They'll probably do what's easiest - if it's distributed as a package which builds everything together (as i suspect it will be) then they'll probably just 'make; make install'. > * The library should be implemented in such a way that multiple versions / > generations of it can be installed simultaneously. Perhaps alternatively, > there should be a mechanism where the library can be queried as to which > API version it is supporting, and/or instructed as to which API version a > client using it understands how to use. > Long term that is a good point, and if you have concrete ideas on how best to achieve this, please elaborate. > Now, let's say a new release of libfossil2 is made with API version Berry > (Berry > Apple). Let's say there is some reason that libfossil2 with API > version Berry is not fully compatible with clients that only know how to > use API version Apple. Now, fossil2scm, because it comes from the fine > folks who brought you libfossil2, has a new version released in conjunction > with the new version of libfossil2 and the new version of fossil2scm is > compatible with API version Berry. However, IDEusingfossil2 does not yet > have a new release that understands API version Berry. > i'm hoping that (A) 95% of the people just keep using the standalone client binary, (B) that the 5% who don't will use an amalgamation build so that they do not have such problems :/. That is the official solution sqlite3 recommends, and i see no reason not to do the same for fossil. That said, sqlite3 has much stricter compatibility requirements than fossil is likely to have. (Maybe we'll be cursed with success and indeed have to cast the API in stone at some point, but then there's always v3 to hack on...) > However, note that if IDEusingfossil2 is able to tell whatever version of > libfossil2 it is linked with "I understand API version Apple, and I need > you to behave precisely as if you are API version Apple", and if libfossil2 > is willing and able to obey this requirement, then it would be possible to > update libfossil2 (and other dependencies) to API version Berry even tho > IDEusingfossil2 is not yet updated to understand that API. > sqlite has functions which allow you to query the linked in library version, and fossil would of course have the same. > * The library should be implemented in such a way that multiple instances > of the library, and/or multiple different clients using either the same > instance of the library and/or multiple different instances of the library, > will not accidentally corrupt fossil repositories. Note that under > Unix/Linux many types of file locking (especially network file locking) are > less than fully secure or reliable. > Those (extremely difficult) details are 100% delegated to sqlite. There's no reason fossil has no directly deal with them. > * It might be worthwhile to reach out to the various major Linux and BSD > Unix distros to see what will make their lives easier in terms of packaging > and distributing libfossil2 and fossil2scm. > i can't personally commit to it, but wouldn't object to it. That said, we're still a long way from even determining if this whole experiment is even feasible. It might turn out that it becomes to difficult to do, that nobody is willing to do it. And that's fine - the whole thing is an experiment at this point and it won't break my heart if it turns out it's just more effort than it's worth. > Localization / internationalization: For at least FOSS projects, I know > there are organizations out there who will do much of the work of > localizing and internationalizing the software for you (in particular > various language strings) As Long As you use software libraries which make > it easy for them to do this. > ideally the core library won't emit any human-language strings except to propagate OS/sqlite3-level errors. > Whether or not these software libraries would affect libfossil2 and > fossil2scm in terms of the software licenses applicable to them (I'm > thinking in particular of GPL / strong copyleft licensing as opposed to > LGPL / weak copyleft or MIT/BSD/Apache/etc non-copyleft licensing), I do > not know off the top of my head. But, the possibility is out there at > least to leverage the work these groups do. > That's good to know. i have no idea what the conventional approaches are for this, but i also have no intention of outputting arbitrary strings from a library (error messages excepted). The l10n/i18n will become the problem of the concrete application(s). > Abstraction around the repo and config DBs: I see two main areas here -- > (1) abstractions which maintain the use of a SQL database, but don't > necessarily mandate sqlite, e.g. MySQL (and its siblings) or PostgreSQL, or > on Windows Microsoft SQL Server, or on everything Oracle, could possibly be > used as the database engine; (2) abstractions which do not mandate the use > of SQL, and in particular ones which permit use of some flavor of a > NoSQL-type engine. (I note that there are several distinct and not > necessarily cooperative things which all fall under the banner of NoSQL.) > Whether or not any of this would be desirable or even worthwhile I > certainly have no idea. > My current thinking is, "abstracting away sqlite3 will be painful," particularly because so much is implemented in terms of sqlite-specific SQL. On another note... We have SSDs now which are very fast but have limited > write cycles. We also have RAM disks available on many platforms. Does > this have any significance to libfossil2 and/or fossil2scm? > Not directly - the vast majority of the i/o happens through sqlite (or "the storage layer") and fossil will not specify/require any particular performance characteristics. HW-level details aren't fossil's domain. If it's running on a 720kb floppy disk it will behave the same (just a lot more slowly). > OS-level peculiarities: There are other multi-platform software projects > which have to deal with these, both with peculiarities between similar > types of platform, such as the various flavors of Unix and Linux, and > between drastically different platforms, such as between the former versus > the different versions of Windows, MacOS/X, ummm, VMS, the IBM mainframe > OSen, etc etc etc. All the major FOSS SQL databases have to deal with > this, the Apache web server (Apache HTTPD) has to deal with this (they have > Apache Portable Runtime IIRC), Gnu Emacs has to do this (tho that would > certainly involve GPL licensed software), I'm sure there's plenty more... > Maybe there's stuff that can be stolen ^H^H borrowed from one or more of > those to avoid having to roll your own. > i think we currently have most of the painful parts already implemented in fossil. e.g. the weird Windows console text conversions and conversion of filename encodings. The existing code works fine for windows/*nix (of various sorts), and i suspect we'll just be recycling that. Strict C89 or commonly-supported C99 extensions: What platforms, and > compilers on those platforms, do you want to be portable to? If everything > you care about is (non-buggy) C99, well... > The only c99 feature i use regularly is <stdint.h> and <inttypes.h>, which eliminate the more glaring of the C89 portability problems. sqlite3 uses (long long) in one place, so it's not strictly c89 portable, but it does indeed work on the majority of C89 platforms. > HTTP/CGI servers: I could see people wanting to use libfossil2 with HTTP > servers other than what is provided by fossil2scm, e.g. Apache, Nginx, > Microsoft Windows IIS, whatever MacOS/X uses, etc. > That's all possible now, and don't imagine that that will go away. Okay, it seems there are still two pages to answer here, but i need to get back to work for a while. i'll respond to the rest later. -- ----- 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
