Kudos and thanks to Dave for taking the initiative. Great work, especially towards integrating the various efforts.
To affirm a few design intents and organizational motivations, the purpose and intent of the 'rt^3' module was (and still is) to be the foundation for a new "unified" framework that would sit on top of the "heart" of BRL-CAD -- i.e., all the code in the 'brlcad' module. Moreover, when the 'rt^3' module was started, we weren't putting C++ code into the 'brlcad' module and given the new unified framework's design was planned to be implemented OO/C++, it made (and still makes) sense to keep the work separate. As for the suggested restructuring, the only issue I see is with the applications and the mix of conventions. For example, application-wise, I don't see a difference between the 'g3d' work and 'iBME' design and the original 'rt^3' effort. I don't think we should keep the original 'rt^3' name, though, and 'g3d' conflicts with the name of another popular project. So we can just call it iBME for now. But!... This new integrated/unified environment is going to eventually be installed as the single application front to BRL-CAD, so it could also just be called 'BRL-CAD' or 'brlcad' as that is what the binary itself will eventually become. All of the binaries and commands of functionality in the core module effectively become plugins and foundation for the new system. Few other comments to think about (not all of which affect the restructure much): * the 'date' directory is a build-system stamping tool (that applies to all products, not just GS). It was a means to guarantee that all application could accurately report their build date even through relinks. The 'brlcad' module does this much better. * the 'lib' prefixes can go away. That's a mix of conventions -- the sub-functionality should 'em or not, but not mixed. Common practice for installed libraries to use that convention, but thus far the only library we're talking about keeping as an API is the GE (which may be a lib or collection of libs). * 'coreInterface' is effectively a combination of what was libGeometry and libRaytrace. The Interface 'suffx' is implicit as part of the GE. Should probably become either 'Core' or 'Geometry' or simply be the contents of GE. * interface and integration tests are relatively low-maintenance. comprehensive unit tests are very expensive. non-comprehensive unit tests tend to decay. GE public API could benefit greatly from unit tests. GS network protocol could benefit greatly from interface tests. GUIs tend to be pretty unstable for anything more than integration tests. * cmake is good. Kudos to Ralith for fixing the 'brlcad' module pkg-config files and getting the new gui cmake build files to use it! Cheers! Sean On Thursday, April 16, 2009, at 09:58AM, "David Loman" <[email protected]> wrote: >Ladies and Gents, > >I am in the process of trying to round up and organize the rt^3 module. It >appears to me that there are three major ongoing efforts happening in >parallel and with little to no communication with each other: > > 1. > > Daniel's coreInterface work > 2. > > Manuel's GUI work > 3. > > My GE/GS work ( heh, attempts really ) > > > With GSoC starting soon (and me returning from Vacation) I realized that >now is a perfect time to try to synchronize, standardize, and organize >things a bit. So here is my proposal. > >I was tasked with bringing the concept of a Geometry Service and Geometry >Engine from paper into reality. The Geometry Engine is to have all the >functionality of the existing brlcad library suite and act as the C++ API >for brlcad. The Geometry Service is designed to utilize the Geometry Engine >while adding in Network capabilities, Access Controls and SVN repository >functionality. The third piece to all of this is a 'thin' or 'dumb' client. > >After lengthy discussions with Sean, Erik and others in the office, it came >to be apparent (to me) that the ultimate goal for the rt^3 is to be the >'Next-Gen' brlcad and that my new tasking fits into that role. The terms >'Integrated Brlcad Environment' and 'Brlcad Modeling Enviousness' were >tossed around during that discussion and gave birth to my notion of an >'Integrated Brlcad Modeling Environment' or 'iBME' (spoken I-Beam). >Realistically speaking, there are no real reasons to use the term iBME over >rt^3 other than the '^' is a pain to type and iBME has a modern(read >trendy?) sound to it. :) > >According to the aggregated design, iBME/rt^3 consists of the three distinct >products mentioned above: Geometry Engine (GE), Geometry Service (GS), and >one or more GUIs/Thin Clients(TC). Following that, I propose the following >source directory structure: (The include directories would be very similar) > >- src/ >- - GUIs/ >- - - g3d/ >- - GE/ >- - - coreInterface/ >- - - date/ >- - - exception/ >- - - io/ >- - - libImage/ >- - - libNumeric/ >- - - libRaytrace/ >- - - libUtility/ >- - GS/ >- - - Jobs/ >- - - netMsgs/ >- - - netMsgActionDefs/ >- - - libNetwork/ >- - other/ >- - - rbgui/ >- - - mocha/ >- - - orge/ >- - - ois/ >- - - uuid/ >- - iBME/ (or rt3) > > > I suggest removing the superceded_GS/ directory as it is no longer needed >and the rt^3/, rt^3d,/ rt^3dbd/, and scratch/ directories as their >functionality will be reproduced in the new rt3/ or iBME/ directory. I also >see the GE/ and GS/ sub directories changing as all of our ideas merge. > >I would like to get moving on the re-org ASAP, preferably within the next >3-4 days. Let me know what you all think. > > > Other Discussion Points: >-Should we implement unit testing? I say yes. >-Should we switch over to CMake? I say yes, while things are still 'simple'. >-We need to agree upon coding standards (aka hash out the Hacking doc) > > > >-Dave Loman > ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
