On Fri, Jul 26, 2013 at 3:17 AM, Joseph R. Justice <jayare...@gmail.com>wrote:
> My apologies for taking so long to respond myself, I've been a little > under the weather the last couple of days. > And a toothache is keeping me offline and my response to your post exceedingly brief... > Long term that is a good point, and if you have concrete ideas on how best >> to achieve this, please elaborate. >> > > I don't have ideas off-hand. I'm just raising the point because I suspect > it will be of value to distributions, and more generally to applications > making use of libfossil2 (especially those applications *not* specifically > provided by TFP). > Let's talk about that, in the following points, on the -dev list. > I'm not sure what an "amalgamation build" is supposed to be. I see >>> http://www.sqlite.org/amalgamation.html which talks about an >>> amalgamation of the sqlite3 library source code into a single .c and .h >>> which can then be incorporated as a source code unit into an application >>> making use of sqlite3. I'm assuming you're talking about doing a similar >>> thing with the source for libfossil2 (which would itself incorporate a copy >>> of the source to sqlite3) to create a source code unit for an application >>> making use of libfossil2? >>> >> Correct. The current prototype is being designed with that in mind and already builds as an amalgamation (a term taken from the sqlite project). > One other thing -- what if the application making use of libfossil2 is > also making use of sqlite3, and perhaps even was already making use of > sqlite3 long before they decided to use libfossil2? If the application is > using an amalgamation build of sqlite3, and starts to use an amalgamation > build of libfossil2 (which itself contains a copy of an amalgamation of > sqlite3 and possibly a copy which is a different version), well... > Those points haven't yet become relevant but certainly will at some point. Fossil currently offers a config option to use (or not) the system-provided sqlite, and i suspect we'll need to stick to that approach. > sqlite has functions which allow you to query the linked in library >>> version, and fossil would of course have the same. >>> >> > Cool. > i've already added this, btw. > * 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. >> > > Cool. I didn't know if (and wasn't claiming that) any of this would be > fossil's problem or not. I just knew that it *was* a problem, and that > *someone* would have to deal with it. > That's one of the areas which is (A) exceedingly difficult to implement reliably and (B) handled very well by sqlite :). This is also a very strong argument for keeping sqlite3/4 as a hard-coded backend, as opposed to abstracting away the storage layer (each implementation would need to make similar sorts of guarantees). Well, I think much of what I've been mentioning above is just this. It >>> also applies to the existing fossil1scm, if only to make sure you all, as >>> the upstream vendor for this application to the various Unix / Linux >>> distros, know what would make their life easier in terms of packaging and >>> distributing the application to each individual distro's users. (Please >>> note, I have *no* role whatsoever in packaging fossil for *any* >>> distribution, and I am not about to start. Each distro already providing >>> fossil1scm has someone already doing that. I'm just trying to do some >>> advocacy and education on behalf of the Unix / Linux distro ecosystem as a >>> whole.) >>> >> So far we've had nobody to who's done any evangelism in that area. > > 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. >> > > That's fair enough, re the core library. It still applies to applications > making use of the core library, however, and there presumably would be at > least one such application developed by > The prototype is still far from being able to say what tools/approaches will/should/could be used to cover translations and whatnot. i personally have no experience with multi-language C apps. -- ----- 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
