Re: open CERTI task 6911 and 6909

[Eric Noulard]

2007/9/27, Christian Stenzel <address@hidden>:
> I'm very new here. To get familiar with CERTI Eric
> assigned me the tasks 6911 (tutorial) and 6909 (test federates).

I confirm and I welcome Christian for
generously applying for working on CERTI with us.


> I prepared a few slides where I introduce my ideas mainly for
> a first tutorial.

Thank you for that
I'll comment the content at the end of the mail.

>
> Follow this link
> http://193.175.118.241/~stenzel/download/CERTI/tutorialCERTI.pdf
> and when asked for a user and password type
> download
> Rs25!

This is a good idea not to through heavy file on a list
and providing a link.
However if your document/file is not too large you may
attach it directly on the tracker (of the concerned task/bug):
https://savannah.nongnu.org/task/?6911

using the "Attach Document" part
(I'm not sure of the exact spelling since I get french "Documents joints"
 interface)

I think you may attach file whose size does not exceed 512 Ko.
Note that after you attach a file you may delete it if necessary
for example for attaching a new version.

> If there are any hints, critque etc. let me know.

here come my comment:

Tutorial Aims:

"demonstrate usage of CERTI API"
I would say that the tutorial should primiraly
"demonstrate usage of HLA RTI API"
and specify clearly if the API used is:
   HLA 1.3
   and/or
   IEEE-1516
   and/or
   CERTI specific

Ideally the tutorial may work for other RTI than CERTI
concerning the API, other parts (rtig, rtia, installation etc....)
may be CERTI-specific and should be identified like this.

I agree with the fact that billard is too complex for a first start.
It lacks design document explaining why RTI API may be deep
inside billard classes.

I'm OK with the refined aims and find the idea of showing
source code a good idea. Regarding this feature I think
you may think of an optional "easily parsable output"
--parsable-ouput command line options which generate
outputs that may be captured and sent to a wrapping GUI.
This is not a _really_ important feature but it could be nice
with almost no more added work.
I'll propose an output format and I may implement the wrapping GUI
you may just think that I (or any other) should easilly be able
to change the way your tutorial send output.

Doxygen usage for documentation is good, I'll post a note
on how to easily generate doxygen documentation using CMake
(as it is [almost] done for CERTI).

I'm Ok with the example application.
One may add one or several
"observer" federates which either store (to file)
or plot the state var of your closed loop controller.

Such "observer" federate may be made relatively generic.

My comment are "comment" nothing mandatory :=).

-- 
Erk