Dave,
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.
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.
I see the core interface more in the line coreInterface-GE-GS than as
a part of GE. However, the real relation between these three will
become apparent only if GE got some substance.
2)
The name “coreInterface” can be changed to something else. We can
also decide about a special prefix for the core interface classes.
This way it will be easier to distinguish them from GE and GS classes
in the /usr/include/brlcad directory (targeting for a BRL-CAD
installation corresponding to the Linux Standard Base).
3)
I would not emphasize the GUI. I would prefer “APPS” for applications
as a first level directory name.
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).
4)
CMake is OK. I am using it for the brlcad.dll anyway.
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 <[email protected]>:
> 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
>
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
