On Jul 8, 2014, at 6:08 PM, Clifford Yapp wrote: > In the interest of joining the fun without making a mess, how do the > following ideas sound? > > Split the "db" functions out from librt into a libbgio library? (gdb > and Gnome got there first with the obvious names, unfortunately...)
Yes! I've had that on my radar as well for a number of years -- that's the "separation of libg" that I was referring to. My thought was just "libg" as they are all routines for loading/reading/writing our format. There aren't any notable uses either. I hadn't yet sorted out how to incorporate the object import/export routines without affecting performance or encapsulation, but it fundamentally amounts to either making libg depend on librt or librt depend on libg. The latter probably makes more sense, but our data types are not currently set up for that relationship at all (and it'd be a lot of work with no visible gain). We should start by moving the db_*() routines first (after confirming that they are db-related and shouldn't be renamed rt_*()). > Making boolweave and related parts (if any) into their own libboolweave > library? Yes, excellent. I'd suggest we expand the scope (and name) just a little bit as weaving is just one piece of the CSG boolean evaluation. That's coincidentally a piece that should do exceptionally well with rt converted into stages where all boolean evaluation happens at once for all pixels... prime for leveraging OpenCL. > Can we eliminate ged API by consolidating commands? (finishing the > edit command, make a "bot" command and stick all the subcommands under > it, etc.?) Ultimately we can eliminate about 350 exported symbols from libged once there's a ged_exec() in place with command registration. It should end up being just a couple dozen functions. Lots of command consolidation is still needed, but that can be happening under the hood. > I know it's not a high symbol count, but could we just fold the sysv > library into libbu? That seems like a job that libbu should handle, > to me... It'd be nice to see if any of those function implementations can just go away now. Many of them predate expecting at least c89 compliance. Also, that library isn't wrapping functions in some improved manner like other bu functions. It's merely providing an implementation of standard functions that should be available but sometimes aren't/weren't; augmenting libc. I don't see much value in having a bu_memset() for example. > Would the chull/obr routines be a logical thing to pull out of libbn? > (libchull is tempting from a naming standpoint...) There are a few > logical additions to that set of functions we don't have implemented > yet... Same question for the random number/noise functions > (regrettibly, libnoise is taken, although the cvs and file histories > don't seem too active...), the bn_wlt_haar_1d_*_decompose functions > and the bn_table functions. A random number library could be useful; the others seem like stretches. Any library we create should stand well on it's own, a lib that would be useful to other projects if we made it's own download. > Are vlists (particularly the font related functions) suitable for > libbn, or do they really belong in libdm or maybe in libbu? The > string->vlist stuff sort of makes sense along side the vfont stuff... Maybe. I don't think it'll make much of a difference in making it significantly easier to use or more logically organized either way. As you note, it could easily fit in three different libs in its current state. Lower hanging fruit and what not. Cheers! Sean ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
