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
