Date: Wed, 26 Feb 2014 12:55:11 -0800 From: Jordan Hubbard <jkh@turbofuzz.com> To: ghostmansd@gmail.com Cc: hackers@freebsd.org Subject: Re: GSoC proposal: Quirinus C library (qc) Message-ID: <DBC06B9D-E9EC-45A4-8768-11B27EEC4571@turbofuzz.com> In-Reply-To: <CAMqzjevCoS2qA7jmpPmOXpfzrsD1LzNMJbC8sw-Op-KB-UMhXQ@mail.gmail.com> References: <CAMqzjevCoS2qA7jmpPmOXpfzrsD1LzNMJbC8sw-Op-KB-UMhXQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_896EA4AB-D3BC-42D5-BD05-1D0E089EED5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dmitry, Let me first just say that this is a great idea - libc has always = traditionally been a very minimalist place to start writing applications = from, and certainly =93lack of high-level API=94 is one of the = traditional Achilles heels of Unix, not just FreeBSD. I can certainly = say from personal experience that the life of an ISV on a Unix platform = is a sad one - you either end up writing a lot of the foundational = libraries yourself and/or you stick together a potpourri of libraries = like apr, glib and gmp to try and give your application a somewhat = higher place to stand, hoping like hell of course that the foundational = libraries you=92ve chosen actually work, and work together! That said, I feel compelled to point out that you=92re also about to = drive into a swamp, and there are lots of alligators and poisonous = snakes in there. :-) If you=92re going to do this, it=92s best to go into it with your eyes = fully open and aware of the magnitude of the challenge you=92re about to = undertake (hint - you will be at least 28 years old before you consider = this =93done=94 enough to walk away, or more likely run screaming, from = it because by then you=92ll be really really ready to move onto = something else!). I don=92t say this to discourage you, I just want to = make sure you=92re fully aware of what you=92re about to undertake if = you=92re truly committed to seeing it all the way through - this is far = more than just a GSoC project! One of the big reasons it=92s such a swamp is the degree to which things = quickly become interconnected inside such a library. You want everything to be I18N compliant by default, so first you = implement the Unicode character handling support and the relevant = character classing functions, and of course Unicode also means strings, = so you implement your own unicode-aware String type and also add a bunch = of convenience functions to Strings while you=92re in there. Then, = naturally, you need to convert other data types (like C strings) to and = from your String type, so you add those functions (and if you want to = see how far that can go - look here!). Once you=92ve done all that = work, you want the rest of your library to use your String type, so now = you=92ve got your second (after the character handling) bit of = inter-connectedness and it just multiplies from there. All your base = types (Strings, Hashes, Arrays, Trees, etc) become consumed by the rest = of the library and any client of gc_lib soon needs to sign up for the = whole package - they can=92t just pick and choose individual functions = as they see fit, and maybe that=92s OK, but that=92s part of the reason = why there are so many competing libraries like this - everyone wants to = own the foundation because it=92s just so much easier when they do! Perhaps all of this has already occurred to you, in which case I=92m = just stating the obvious, but having written such libraries myself = (libxtr - stood for =93extra functions=94 - back in the 1990=92s) and = also having had recent experience with Apple=92s Foundation libraries, = which do everything you just described and a lot more, I figured it = wouldn=92t hurt to point it out. Anyway, on to the specifics: On Feb 25, 2014, at 12:24 AM, Dmitry Selyutin <ghostman.sd@gmail.com> = wrote: > 1. Strict and universal interface. Each function begins with qc_ = prefix, > followed by type if function is type-related. Yep, it=92s good you put that first. If the names don=92t make sense, = nobody can remember what to call and the library is useless! Uniform = calling conventions for everything is also obviously important. > 4. Universal file system path type. It is possible to achieve > cross-platformness using such path types, i.e. it is possible to make > directories, links, symlinks, remove files, directories, etc. = regardless of > platform path API. Here, however, I think you might want to really consider the role of = this library. Is it a =93higher level library for BSD=94 or is it a = cross-platform development library that caters to non-Unix platforms as = well? You mentioned Windows earlier in the document, and if so then = that=92s cause for concern because if you really want to make it a = cross-platform library then you=92re going to be faced with lots of = different constraints that just don=92t apply to FreeBSD and will = seriously limit the approaches you can take. Moreover, the code itself = will be a lot uglier if it has to compile on Windows (or = $someOtherNonUnixOS) as well, and you will spend a substantial amount of = time and energy just impedance matching the library to the different OS = foundations. Personally, I think it should be a non-goal to make this library = cross-platform. There are already plenty of other good cross-platform = development libraries out there if that=92s what an ISV wants to do, = whereas there is no =93better libc than libc=94 library for *BSD, which = holds native development back. More importantly, if you just focus on = BSD as your foundation, you can make a lot of assumptions and leverage = the power of the underlying OS in ways you just won=92t be able to do if = you want this to also work on Windows. > 6. Multithreading support if platform permits it. On POSIX we use = pthreads, > on Windows we use its API for multithreading. I'm also thinking about = green > threads implementation. Thread local storage is already implemented, = yet > there is still a lot work to be done with threads, mutexes, etc. Please don=92t reinvent pthreads. They already suck enough in libc. :-) I=92ve been up on the libdispatch soapbox so many times that I=92m sure = people here are tired of hearing it, but seriously, once Grand Central = Dispatch became firmly embedded in iOS and OS X, the app writers never = looked back at pthreads again because GCD is just so much easier to use, = and takes so much of the pain out of parallelism, that I=92ve received = countless emails from developers crying that they were recently forced = to go back to pthreads on some other platform and had forgotten how = horrible and painful the experience was! GCD has also been ported to = Windows, Linux and Android (again, by some of those same developers who = just would not, could not, go back to pthreads on Android) largely on = the strength of how much better an API it is for multi-threaded = programming. It=92s also been ported to FreeBSD (Hi Robert) so there=92s = really just no need to re-invent this wheel. The source code is there, = it works, just make it a subset of your library. Its dependencies are = deliberately very small because we wanted it to be low-level and = cross-platform. > 9. A lot of other things to be done, such as unified I/O streams which > provide compression/transformation filters, protocols, math library, = etc. Look at GCD=92s async I/O functions and, if you want to create = transformation/compression filters, you really can=92t do better than = Security Transforms as a model. Don=92t let the name fool you - they = were created for cryptographic tasks, but they=92re really a generic, = multithreaded, data pipelining model. If I had those to do over again, = I would not have had them called SecTransforms at all but merely added a = Transform API to GCD and then built SecTransforms on top! The rest of your proposal looks fine to me - date functions, unicode, = etc - all pretty standard stuff. Like I said, I have pretty recent = experience with this with Core Foundation (see also OpenCFLite) and it=92s= all doable and very useful, you just need to remember all the caveats = in my first paragraph! :-) - Jordan --Apple-Mail=_896EA4AB-D3BC-42D5-BD05-1D0E089EED5E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlMOVLAACgkQA00ZyjuMuWzGsAD/Yy20mrOgqFiDHkWT6tnYR3zD nr9p7oGmn8fKpmtE7DoA/3aRwkwdRI3VjrkDk2fgrcsqaM5hiJ715HiC35F/J+Ik =CopF -----END PGP SIGNATURE----- --Apple-Mail=_896EA4AB-D3BC-42D5-BD05-1D0E089EED5E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DBC06B9D-E9EC-45A4-8768-11B27EEC4571>