Re: [brlcad-devel] RT^3 src/ re-org proposal

[Christopher S. M. <br...@ma...>]

On Apr 17, 2009, at 11:32 AM, Daniel Roßberg wrote:

> 1)
> I would like to see the coreInterface on the same level as GE and GS.
> This is because the core interface is an independent effort with
> slightly different objective then GE.

I find that sentiment very unexpected, actually, because the core  
interface API and implementation as it currently stands is nearly  
_exactly_ what I'd envisioned for the GE originally.   The only thing  
I see different about the objective is perhaps that it is a subset of  
the eventual long-term goals.  For the near-term, though, it's pretty  
much in-line with what the GE is supposed to be.

> The core interface has not the universal demands as GE.  For example
> it has only rudimentary vector classes.  This is because the
> applications using the core interface usually have their own numerical
> library.  There is no need to introduce a new one.

Again, that just makes it a subset.  If the GE needs to pick up more  
extensive numerical facilities, they 'could' be added, but even that  
isn't on the plan.  The basic goal right now is just geometry  
representation, basic manipulation (like name changes), and ray-tracing.

> 3)
> I would not emphasize the GUI.  I would prefer “APPS” for applications
> as a first level directory name.

Agreed.  I would even prefer to keep the applications at the same  
src/ level, but I can just as easily concede putting them all into a  
subdirectory.

> I would expect many different applications on top of GE and GS.  The
> GUI is only one of them.  Many people may find it more convenient to
> program a converter on top of GE then on librt (for example).

Quite true and exactly the reason for the firm separation of GE from  
GS too.  One is effectively an OO-LIBRT API, the other is a network  
service.

Cheers!
Sean


> BTW, one of the next releases of the brlcad.dll will include the core
> interface.  I plan to make this the standard for the brlcad.dll.
>
>
> Regards,
> 	Daniel
>
>
> 2009/4/16 David Loman <dlo...@gm...>:
>> 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:
>>
>> Daniel's coreInterface work
>>
>> Manuel's GUI work
>>
>> 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
>>