taskCERTI - Tasks: task #6893, Implement notification services

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #6893: Implement notification services

Submitted by:  Eric NOULARD <erk>
Submitted on:  Tue 15 May 2007 02:05:53 PM UTC  
 
Should Start On:  Mon 14 May 2007 10:00:00 PM UTC Should be Finished on:  Mon 14 May 2007 10:00:00 PM UTC
Category:  HLA 1.3 compliance Priority:  5 - Normal
Status:  In Progress Privacy:  Public
Percent Complete:  60% Assigned to:  Eric NOULARD <erk>
Open/Closed:  Open Planned Release:  UnplannedRelease
RTI Service Groups:  Declaration Management

( Jump to the original submission)

Tue 28 Apr 2009 02:25:38 PM UTC, comment #79: 

5/  6 Testing test_NotificationSwitches        Passed

Thank you Christian.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Tue 28 Apr 2009 01:39:51 PM UTC, comment #78: 

since yesterday new dtest script is in cvs
dtest_test_NotificationSwitches

Christian Stenzel <approx>
Project Member
Thu 23 Apr 2009 12:30:13 PM UTC, comment #77: 

I just would like to be sure that
new implemented features get tested systematically,
i.e. have a test program + a dtest script
in HLA TestSuite.

This way those features won't be trashed by forthcoming
patches and evolution.

Thus, don't worry too much about delay,
I just wanted to ensure there will be a dtest script.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 23 Apr 2009 11:51:14 AM UTC, comment #76: 

Hi Eric,

I try to implement a dtest script at the weekend. Hope that this is fast enough.

>>Since some of switches are now implemented would you
>>be possible for you to either:


In my opinion the switches are already implemented. You can set a flag within a federate by using the appropriate methods below:

enableClassRelevanceAdvisorySwitch(),
disableClassRelevanceAdvisorySwitch

enableInteractionRelevanceAdvisorySwitch(),
disableInteractionRelevanceAdvisorySwitch

enableAttributeRelevanceAdvisroySwitch(),
disableAttributeRelevanceAdvisorySwitch()

enableAttributeScopeAdvisorySwitch(),
disableAttributeScopeAdvisorySwitch()

What is left are the required callbacks. Only startRegistrationForObjectClass works at time.

Bye

Christian Stenzel <approx>
Project Member
Thu 23 Apr 2009 09:43:20 AM UTC, comment #75: 

Hi Christian,

Since some of switches are now implemented would you
be possible for you to either:

 - write a dtest script for your
   test_NotificationSwitches

and/or

 

 - describe the test sequence implemented in the test
   such that I may be able to write the dtest script myself.

If you decide to document the test sequence in the code
may be you can use some MSC decsription which can then
be processed using some tool like mscgen
(http://www.mcternan.me.uk/mscgen/)

MSC is well suited for describing sequence of message exchnage
between processes. Moreover is you mscgen format
for describing MSC we can generate neat graphic.
Moreover doxygen comments may includes MSC:
http://www.stack.nl/~dimitri/doxygen/commands.html#cmdmsc.

This is just a suggestion, just do what you can/want.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 08 Apr 2009 10:51:56 AM UTC, comment #74: 

Just committed.

Next week I proceed with stopRegistrationForObjectClass .

Happy Easter!

Christian

Christian Stenzel <approx>
Project Member
Wed 08 Apr 2009 09:28:26 AM UTC, comment #73: 

Yes,
go ahead.

However add the try/catch in order to avoid
the assert error.

Put a comment

/* FIXME

  • appropriate comment */

before the try catch as a reminder to investigate the
design issue behind this "inside RTIA subscription".

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 08 Apr 2009 05:38:30 AM UTC, comment #72: 

Hi Eric,

how to proceed? Can I check in the patch?

Christian Stenzel <approx>
Project Member
Fri 03 Apr 2009 07:16:15 AM UTC, comment #71: 

One last remark to my post

I suppose that no one tried to unsubscribe/re-subsribe an object class before with already discovered objects.

Christian Stenzel <approx>
Project Member
Fri 03 Apr 2009 07:09:09 AM UTC, comment #70: 

forgot the new patch.

(file #17856)

Christian Stenzel <approx>
Project Member
Fri 03 Apr 2009 07:07:32 AM UTC, comment #69: 

Hello,

>Your latest Notif patch may be applied to the new
>HEAD without trouble, however I urge you to
>update your tree before having conflict.


I made a fresh checkout and merged the patch. The patch is attached at the tracker.

>Is it precisely the purpose of the advisory switches to
>"auto-register"?
> Why do we have two registerOjectInstance calls?


This is of course not the purpose (as I know). But the advisory switches are not the cause for that behaviour.

Instead it is a problem within the discoverObj callback of RTIA.

The auto-registration takes place within RTIA by receiving the callback discoverObjInst.

This means for the subscriber in our test scenario:

The first discover callback auto-registrates the objectclass. Following an unsubscribe call do not delete already registered object classes at time. That's why a re-discovering by a new subscribe throws the exception ObjectAlreadyDiscovered because the RTIA/ObjectManagement::discoverObject tries to re-register an already known object class.

The problem arises also without applying my patch. This is a problem also in the current CERTI tree. I suppose that no one tried to unsubscribe/re-subsribe an object class before.

Perhaps this should be analyzed in a different bug/task.

> Usually Federate do registerObjectInstance,
> why does RTIA/ObjectManagement::discoverObject
> call registerObjectInstance?


this is a good question. Why does a subscriber (within RTIA) register object instances? Perhaps this is the way to inform the subscriber about object attribute updates etc. through the RTIA.

Christian Stenzel <approx>
Project Member
Thu 02 Apr 2009 08:02:22 PM UTC, comment #68: 

Christian,

I've just merged-in a long-standing relatively big patch
which was made by Petr in order to restore a clean
windows build.

see
https://savannah.nongnu.org/bugs/?24930

Your latest Notif patch may be applied to the new
HEAD without trouble, however I urge you to
update your tree before having conflict.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 02 Apr 2009 02:28:53 PM UTC, comment #67: 

Hi All,

Petr:
Thank you for the analysis and the associated bug report.
I did add a dependency link to the new bug for current task.

Christian:
I do not fully the test case.

Why do we have two registerOjectInstance calls?

Usually Federate do registerObjectInstance,
why does RTIA/ObjectManagement::discoverObject
call registerObjectInstance?

Is it precisely the purpose of the advisory switches to
"auto-register"?

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 02 Apr 2009 12:03:20 PM UTC, comment #66: 

Thanks for your investigation.

This is indeed the problem.

For a fast test I did the following within
RTIA/ObjectManagement::discoverObject

...
 try {
    rootObject->registerObjectInstance(fm->federate, the_class,    the_object,
    req.getName().c_str());
 }
 catch (ObjectAlreadyRegistered) {
 }
...

Now the assert do not occur. So obviously you find the problem.
Thanks again.

The problem here is that the first discoverObject callback in the test_Notification federate registers also the object instance.

After the resubscription the second discoverObject callback try to register an already registerd object class.

We have some possibilities to handle the situation:

1) catch exception like shown above

2) each unsubscribe deletes all registered object instances of the object class

What do you think is a good solution for this case?

 
Christian Stenzel <approx>
Project Member
Thu 02 Apr 2009 09:46:53 AM UTC, comment #65: 

Christian, Eric,

I found the cause.

The TICK_NEXT means that the processOngoingTick() call is active. The assert() you're getting means that the processOngoingTick() raised an exception, so the TICK_NEXT "survived" the processOngoingTick() execution.

The current RTIA ticking mechanism is not ready to receive any exceptions. This is not OK, but worked so far. ;-)

The exception (ObjectAlreadyRegistered) is thrown by ObjectManagement::discoverObject, more precisely by rootObject->registerObjectInstance.

The execption is originated by ObjectSet::registerObjectInstance.

Petr Gotthard <gotthardp>
Project Member
Wed 01 Apr 2009 08:14:37 PM UTC, comment #64: 

Hello Petr, hello Eric,

thanks for your information.

When you apply my last patch attached at the tracker, the error occurs if you uncomment both commented lines within the subscriber part of current test_NotificationServices federate in the HLA_Testssuite folder and then compile and execute the test_Notification federate (see my last post).

The creator (publisher) of the federation publishes an object class. Next, the creator registers an object instance.

The second federate subscribes to that object class and you will hopefully see that the creator get the callback startRegForObjClass (thanks to the patch). The subscriber should get the callback discoverObjInst.

Everything seems to work, but now the subscriber unsubscribes the object class. After that, the subscriber re-subscribes to the object class.

the creator (publisher) should get again the callback startRegForObjClass (works for me). The subscriber should get the callback discoverObjInst (works also for me).

But at the same time I get that error also described by Eric:

> The trouble here is that the RTIA end up in execute with a
> tm->_tick_state == TICK_NEXT


Additionally, if you never register an object within the creator you can subscribe and unsubscribe to an object class as ever you want. All works as expected, the creator will get its callback startRegForObjClass after every resubscription.

So, my first suggestions aimed to the recursive discovering process invoked within ObjectClassSet::subscribe.

But perhaps I've only made a implementation fault.

At time I do not know the reason.

I'm not sure where to start the troubleshooting. My first idea was to ask the CERTI community. Perhaps anyone knows immediatly how to solve that problem.

I add some explanations about the CERTI subscription process as I understood it into the patch as code comments.

I'm also not sure if I understand the post of petr correctly:

> It's a transient state indicating a tick() callback has been
> processed, but tick() hasn't completed yet.


What do you mean with "tick() hasn't completed yet".

Christian Stenzel <approx>
Project Member
Wed 01 Apr 2009 04:37:45 PM UTC, comment #63: 

Quick answer, without looking deep into the problem yet:

> The trouble here is that the RTIA end up in execute with a
> tm->_tick_state == TICK_NEXT
>
> why it is not allowed to be in this state?
> what lead the time management to this state?


The TICK_NEXT state occurs in an ongoing tick(). It's a transient state indicating a tick() callback has been processed, but tick() hasn't completed yet. The RTIA::processOngoingTick() state machine is probably broken.

Could you give more details on where the unexpected state appears and when?

Petr Gotthard <gotthardp>
Project Member
Wed 01 Apr 2009 04:18:32 PM UTC, comment #62: 

I did your patch a try.
The good thing is that the current patch does not
break current test (automated part of HLA_TestSuite and billard)
however when I do uncomment the offending
re-subscription in the federate I do get RTIA assert error too:

The trouble here is that the RTIA end up in execute
with a
tm->_tick_state == TICK_NEXT
which is not expected here.

I do not manage [yet] to understand either

1) why it is not allowed to be in this state?
2) what lead the time management to this state?

I add Pierre and Petr as cc because they master TimeManagement
tick state handling, may be they can help us with this.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 27 Mar 2009 03:28:10 PM UTC, comment #61: 

Hi Christian,

The talk did go fine,
I think we may have more CERTI interested people after that.

I'll take the plane today at 23:00 (local time)
I should be able to have a look (and try) to your
patch at beginning of next week.

Regarding the assertion failure it may have to do
with the "tick state".

Will have a look at it too.
More information next week.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 27 Mar 2009 01:34:31 PM UTC, comment #60: 

Hi Eric,

hope you had a successful conference talk.

I added again a small patch. Now, the callback startRegistrationForObjectClass is forwarded to the federate.

Please review the patch, so I can advance my work. Also I added some comments regarding future and current implementation details. Perhaps we can talk about it.

I tested with all existing dtest scripts and billard. Everything seems to work.

I also checked in a new version of the test_Notifcation federate.

Everything works, the callback startRegForObjIns is forwarded to the publisher of the objectClass. BUT: You will see that I uncomment two lines in the subscriber part of the test federate.

These two lines realize a resubscription. Since the creator of the federation publishes and registers an object the subscriber should rediscover the object after resubscription.
When the code is executed, the subscriber terminates with an error message. I put the error message as comment in the test federate code (subscriber part) too. The error says: "RTIA.cc:170: void certi::rtia::RTIA::execute(): Assertion `false' failed."

At time I can not say what are the reasons for that behaviour. Perhaps you or anyone else can help.

(file #17819)

Christian Stenzel <approx>
Project Member
Mon 15 Dec 2008 06:02:29 PM UTC, comment #59: 

Ok Go ahead for check-in this one apply.

One more small change may be:
If you have the choice put doxygen comment in
the header file (Federation.hh)
not in the body (Federation.cc).

> In my opinion we should iterate relativly often through
> the code changes. So we can discuss the changes in more detail
> (only for the first time implementing notification services


No problem I'll try to answer fast.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Mon 15 Dec 2008 05:02:13 PM UTC, comment #58: 

Okay again a patch hopefully compatible with your
advices.

If you have no further remarks I'd like to check-in that
small patch.

In my opinion we should iterate relativly often through
the code changes. So we can discuss the changes in more detail
(only for the first time implementing notification services)

Later I would provide bigger patches.

(file #17072)

Christian Stenzel <approx>
Project Member
Mon 15 Dec 2008 12:07:22 PM UTC, comment #57: 

I have two remarks:

1) when using some container type it could be easier
   (to read and use) to typedef it inside the class
    containing the getter

for example:
    in ObjectClass.hh you may

    public:
       typedef std::list<ObjectClassAttribute*> AttributeSet_t

       ...
        AttributeSet_t getAttributeSet(void);
       ...
    }

then in Federation.cc
    ObjectClass::AttributeSet_t attrForObjClass = objectClass->getAttributeSet();

in the same way in ObjectClassAttribute.hh
you could make the existing
typedef std::set<FederateHandle> PublishersList;
public, may be with
typedef std::set<FederateHandle> PublishersList_t;

This is particularly interesting to do that with STL container
since most of the time you may replace a list by a set or
vector by only changing the typedef.
Whatever the use case the typedef name should be easier
to read/understand.

2) In the Federation.cc loop I think your
current proposal may call
startRegistrationForObjectClass too many times because
you may get the same publisher for different attributes:

HLA 1.3 doc says
"the specified object class is advised because at least one of the class attributes that the federate is publishing"

It is not told but I would avoid sending 2 notif message
to the same publisher if it's done on "ObjectClass" basis
and not on "ObjectClassAttribute" basis.

I think you may do it in 2 steps.
a) build the set of the publisher that should be notified.  
   (the set should not contain duplicate)
b) notify the publishers in the set.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Mon 15 Dec 2008 09:03:59 AM UTC, comment #56: 

Hello Eric,

I've attached a small patch.

That patch is for reviewing only. It implements a
possibility how information for the current publishers
of an object class can be retrieved.

I'd like to know your opinion about that implementation.

If you like that approach I would resume my work and implement
the final callback startRegForObjClass hopefully at the end of
this week (then also with doxygen comments).

(file #17069)

Christian Stenzel <approx>
Project Member
Thu 27 Nov 2008 10:08:18 PM UTC, comment #55: 

Personal informal comments :=)

> ObjectClassSet::subscribe
> - call recursiveNotification method
> - recursiceNotification method -> implementation in ObjectClass.cc


Why do you need recursivity here?
You want to notify on each subclass of each class
in the class set?

> - required methods ObjectClass:.isFederatePublisher or/and
> ObjectClassAttribtue::isPublishing


What would be the prototype of those methods?

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 27 Nov 2008 03:02:43 PM UTC, comment #54: 

The following notes are concerned to the implementation
of start- and stopRegistrationObjectClass Federate Services.

This are mainly personal notes and can be regarded as implementation proposal:

In
ObjectClassSet::subscribe
- call recursiveNotification method
- recursiceNotification method -> implementation in ObjectClass.cc

In ObjectClass::subscribe
- test if attribute are already published, return boolean (probably by reference)
- required methods ObjectClass:.isFederatePublisher or/and
ObjectClassAttribtue::isPublishing

Christian Stenzel <approx>
Project Member
Fri 21 Nov 2008 04:43:08 PM UTC, comment #53: 

The screenshot has been done on Linux with CMake 2.6.2.

On Linux you have 3 cmake executables:
cmake     : the command line
ccmake    : the ncurse TUI
cmake-gui : the QT GUI

if you are using CMake 2.4.x you only have cmake and ccmake.

You may SET ANY project OPTION using either command line
or UI.
The value found in the CMakeLists.txt should only be
the "default value" when nothing is specified by the
average user.

But you are not an average user :=) So... keep reading

If you use the command line you may change global option using:
cmake -D BUILD_DOC:BOOL=ON -D BUILD_DOC_DEVELOPER:BOOL=ON /path/to/source

using ccmake:

ccmake /path/to/source

then edit using the TUI and hit [c]onfigure as many time as needed then [g]enerate.

with cmake-gui see and click :=)

> But this seems not enough, only the user and the install docs
> are generated by default.


Yes you  need to both generate the doc i.e. BUILD_DOC
then activate developer doc: BUILD_DOC_DEVELOPER.

We did not activate this "by default" because the
run of doxygen for generating the whole DEVELOPER DOC
may last several minutes.

> "DOT tools"


is the tool used by doxygen to draw graph.
(this is a command named 'dot')
It is part of the graphviz package:
http://www.graphviz.org/
which should be available for many linux distro
and Windows too.

The dot tool should not be mandatory but if you
have it you'll have better looking doc.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 21 Nov 2008 04:28:26 PM UTC, comment #52: 

Hmmm, I'm confused. I do not know and not have such a GUI
for UNIX-like systems. I know that only from Windows.

So where to set the global options within a file. I always
thoughtthat I have to do it with the toplevel CMakeLists.txt file.
There is an option BUILD_DOC which I can switch to on.

But this seems not enough, only the user and the install docs
are generated by default.

That's why I changed doc/CMakeLists.txt I set the Build devel
option to on.

Perhaps I do not known where to set global options?

And another question is concerned to the so-named "DOT tools"
My cmake run in a build dir says that it cannot find the
dot tools.

Christian Stenzel <approx>
Project Member
Fri 21 Nov 2008 02:38:31 PM UTC, comment #51: 

You don't have to edit the file.
There is a GLOBAL OPTION in the main CMakeLists.txt.
See the attached screenshot (of cmake-gui).


Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 21 Nov 2008 01:56:13 PM UTC, comment #50: 

Okay, find the solution.

Have to edit doc/CMakeLists.txt within the source dir
and set dev docs to on.

Christian Stenzel <approx>
Project Member
Fri 21 Nov 2008 01:46:41 PM UTC, comment #49: 

Okay, I adapted the comments a little bit and made a
new commit.

How can I build a API doc? To set the option in the CMakeLists
file only build Install and the user manual?

Have I do it by hand using doxygen?

Christian Stenzel <approx>
Project Member
Fri 21 Nov 2008 12:36:18 PM UTC, comment #48: 

Hi Christian,

Your comment are fine and I think that if everyone
does this "no so little" effort each time we implement
or update and API we will have a much greater source code
understanding and quality.

I have 2 small remarks:

  1) It's usually better to put function documentation
     in the header file (.hh) that in the body file (.cc)
     since such documentation should be seen as a specification
     for the API.
     Moreover when API is public (i.e. whe .hh is exported)
     the user may have a look at the header file in order
     to find valuable information.
     He may not find it in .cc since he may not have it.

     Implementation detail may/should be put in .cc
     In this case they cannot be attached to an API but
     your may create a @defgroup Whatever .

    

  2) You may usually remove "This method", because
     we already know that the comment concerns the following
     method (this will be explicit in Doxygen generated
     doc too).

     You may ommit @return when void.
     It may be interesting to add the intent of the parameter
     using @param[in], @param[out] or @param[in,out]

     You don't have to specify the type of the param because
     it's already part of the API unless you give a more
     precise information, i.e. int considered as boolean or
     enum value etc...

    For example (from RTIG/Federate.hh)
    /**
     * This method sets the ClassRelevanceAdvisorySwitch of the federate
     * to the value of the input parameter val. The CRA switch is enabled
     * by default.
     * @param val is a boolean [true, false]
     * @return void
     */
     void setClassRelevanceAdvisorySwitch(bool val) { cras = val ; };

    May become:
     /**
     * Sets the ClassRelevanceAdvisorySwitch of the federate
     * to the value of the input parameter val. The CRA switch is enabled
     * by default.
     * @param[in] val new value for the switch true means enable
     *            false means disable.
     * @return void
     */ 

    

Those remarks are just "advices" you may commit as-is.
I should have sent recommandation for doxygen comment on
certi ML, I'll do it soon.

Concerning the switches semantic I do not have time
to look at it deeply for now.
I suggest we do it iteratively beginning with your
understanding.

I know Patrice is using the feature with other TI
may be he can explain us his understanding of the service.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 21 Nov 2008 12:05:19 PM UTC, comment #47: 

Hello Eric,

in the attached patch I added important doxygen comments. Especially the ones within libRTI/RTIambassador.cc can be
used for further discussion. I'm absolutely not sure if
I understand all switches completely. So that's why I added
a relatively big comment how I understand them within that file.

I modified my sources a little bit too.

>>Message req, rep ;
>>
>>req.type = Message::ENABLE_ATTRIBUTE_RELEVANCE_ADVISORY_SWITCH
>>;
>>/* what is the meaning of the boolean here...*/
>>req.setBoolean(true);
>>privateRefs->executeService(&req, &rep);


You gave my a good question and obviously we do not need
taht booleans because we have two methods to disable and
enable any switch.

So I removed that boolean from my messages completely.

(file #16891)

Christian Stenzel <approx>
Project Member
Thu 20 Nov 2008 06:25:31 PM UTC, comment #46: 

Hi Eric,

I just checked in.

Tomorrow I will add some doxygen comments.

Next week (hopefully) the second part will follow.

Then we have to implement the required callbacks and
the logic in combination with the switches.

Christian Stenzel <approx>
Project Member
Thu 20 Nov 2008 03:43:23 PM UTC, comment #45: 

Seems OK to me.
Would please add a comment when working on Message,
because some fields of Message are used for different
purposes thus it will ease code reading:

    Message req, rep ;

    req.type = Message::ENABLE_ATTRIBUTE_RELEVANCE_ADVISORY_SWITCH
;
    /* what is the meaning of the boolean here...*/
    req.setBoolean(true);
    privateRefs->executeService(&req, &rep);

In the same vein, adding a proper doxygen comment
to new API is a good practice:

void setClassRelevanceAdvisorySwitch(bool val) { cras = val ; };
    void setInteractionRelevanceAdvisorySwitch(bool val) { iras = val ; };
    void setAttributeRelevanceAdvisorySwitch(bool val) { aras = val ; };
    void setAttributeScopeAdvisorySwitch(bool val) { asas = val ; };

    bool isClassRelevanceAdvisorySwitch() const { return cras ; };
    bool isInteractionRelevanceAdvisorySwitch() const { return iras ; };
    bool isAttributeRelevanceAdvisorySwitch() const { return aras ; };
    bool isAttributeScopeAdvisorySwitch() const { return asas ; };

Concerning the notif test in HLA_TestsSuite we will need
a dtest script for it. I'll help you to do it.
Wait a moment before writing it since I must fix a design bug
in the way the test suite is run.
https://savannah.nongnu.org/bugs/?24891

Besides that you can check-in.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 20 Nov 2008 09:58:48 AM UTC, comment #44: 

Okay, now I tested the patch with the test_Notification federate from the HLA_Testssuite folder. I've seen that I've forgotten the replies from RTIG back to RTIA. That's why again a new and now hopefully working patch.

(file #16884)

Christian Stenzel <approx>
Project Member
Thu 20 Nov 2008 08:14:45 AM UTC, comment #43: 

Thanks Christian,
I'll have a look this afternoon.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 20 Nov 2008 07:52:24 AM UTC, comment #42: 

Sorry, I've just reviewed my own patch and find some mistakes. The defualt initialization for the switches ara and asa are false, not true.

That's why only the last patch is the correct one.

(file #16882)

Christian Stenzel <approx>
Project Member
Thu 20 Nov 2008 07:44:03 AM UTC, comment #41: 

Now I really attached that patch ;)

(file #16881)

Christian Stenzel <approx>
Project Member
Thu 20 Nov 2008 07:42:45 AM UTC, comment #40: 

I attached a first major patch. It implements the
switches CRA, IRA, ARA and ASA.

Christian Stenzel <approx>
Project Member
Tue 18 Nov 2008 10:07:50 PM UTC, comment #39: 

> Thanks for your hints. But what I've meant is concerned
> to switches. For example we have the routines
> enableClassRelevanceAdvisorySwitch(), enabled by default and
> disableClassRelevanceAdvisorySwitch.
> So, the question is, where to store that flag/switch.


OK now I understand.

> My proposal was to use RTIG/Federate.hh/cc because
> there are also the constrained and regulating flags stored.


Yes I agree go ahead with this solution.
Should be on RTIG side since it is up to the RTIG to
implement the notification.

> Map is probably not the correct term, perhaps array
> or matrix fits better. Have a look at the tables in
> chapter 5 (l'heritage ...).


I'm afraid the array described at the top of page 38
of the report does not exists (any more?) as presented.

The RTIG build a "ObjectClassBroadcastList" using
ObjectClass::updateAttributeValue method
the RAV message is sent from within this method and
the resulting ocbList may be forwarded at upper level
to parent class in order to handle broadcast to
parent class subscriber.

I'm not 100% sure its the best algorithm on earth for doing
that but it's currently working.

If you came up with a better (may be simpler) idea to
implement such broadcast, do no hesitate to explain your
ideas.

If adding comments to the current code helps you in understanding
how it works do not hesitate either.
Source code (or API) comments are
as valuable as missing feature implementation.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Tue 18 Nov 2008 06:09:22 PM UTC, comment #38: 

Map is probably not the correct term, perhaps array
or matrix fits better. Have a look at the tables in
chapter 5 (l'heritage ...).

>>You should know that most of the subscriber/publisher
>>informations are currently stored in the
>>Federation::RootObject
>>...
>>What I want to point out is that before adding
>>more information into Federate.cc/.hh have a look
>>at the RootObject hierarchy of informations since
>>you have the hand on it in Federation.hh.


Thanks for your hints. But what I've meant is concerned
to switches. For example we have the routines
enableClassRelevanceAdvisorySwitch(), enabled by default and
disableClassRelevanceAdvisorySwitch.

So, the question is, where to store that flag/switch.
If it is stored in RTIA, we have to transfer a startRegistrationForObjectClass message for each
subscription form RTIG to the RTIA of the publisher(s)
of the object
class attributes. That is the same for all other notification
services. Then we can decide within RTIA if we transfer
the callback up to the federate depending on the switch status.

If we implement the switch information within RTIG only the
necessary message transfer is needed. I think that this is
more performant. So where to implement that information on the
RTIG side? My proposal was to use RTIG/Federate.hh/cc because
there are also the constrained and regulating flags stored.

Christian Stenzel <approx>
Project Member
Tue 18 Nov 2008 03:53:25 PM UTC, comment #37: 

First concerning the map.
I do not understand your question?
What kind of map?
Which page of the report are you referring to?

Concerning the information to be stored.
You should know that most of the subscriber/publisher
informations are currently stored in the
Federation::RootObject

see
RTIG/Federation.hh:71
RootObject *root ;

this root object is first created when the FOM file is parsed
and contains a tree-like structure which mimics the FOM
hierarchy.

in particular you find (see libCERTI/RootObject.hh)

   

    ObjectClassSet *ObjectClasses;
    InteractionSet *Interactions;
    ObjectSet      *objects;

in particular ObjectSet is the set of ALL published
Object. This set is "flat" but you can find object instance
from ObjectClasses set in which you may find in each
ObjectClass the list of published object (and attributes).

In Object.hh you'll find
std::list<FederateHandle *> sf ;

which is the list of federate subscribing to the
corresponding object class.

conversely in
ObjectClassAttribute.hh contains:

 PublishersList publishers ; //!< The publisher's list.

which should be the list of publishers of this
ObjectClassAttributes

since ObjectClassAttributes is a "Subscribable"
it contains:
std::list<Subscriber> subscribers ;

which is the list of subscriber to this ObjectClassAttributes.

Sorry for may be being unclear but those area of code
are relatively new to me too :-)

What I want to point out is that before adding
more information into Federate.cc/.hh have a look
at the RootObject hierarchy of informations since
you have the hand on it in Federation.hh.

i.e. teh RootObject currently contains most of the
informations about the running federation.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Tue 18 Nov 2008 03:01:06 PM UTC, comment #36: 

Don't hurry. I will be back tomorrow.

Christian Stenzel <approx>
Project Member
Tue 18 Nov 2008 02:33:42 PM UTC, comment #35: 

Ok fine.
I'll be back in a few minutes,
I need to read some code.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Tue 18 Nov 2008 02:24:44 PM UTC, comment #34: 

Hello,

I've just started. First I try to implement start/stop
RegistrationForObjectClass (RFOC)

What do you think of the idea to expand the information
holded in RTIG/Federate.cc . Here we can hold switches and so on.

The subscribeObject routine in RTIG/Federation.cc can iterate
through all federates and initiate all required callbacks (RFOC)
on basis of the information hold in RTIG/Federate.cc.

On that level we can collect all required information.

Another question: Do you know where I find that map referred
in the rapport du stage you've send me? In chapter 5 the
principle implementation is explained. I suggest that useful
information can be found within step 2 (debut) and step 3 (diffuser).

Christian Stenzel <approx>
Project Member
Sat 08 Nov 2008 06:26:11 PM UTC, comment #33: 

Yes and No.
I'm doing some necessary refactoring and redesign
of the ObjectRoot/InteractionClass/ObjectClass/...

At the beginning I did it for definitely fixing
https://savannah.nongnu.org/bugs/?23730

Afterwards I wanted to continue a little bit
more refactoring  in order to ease external
contribution and in particular
your work on Notification Services.

I don't really want to do the Notification Services
unless you are unable (missing time may be) to do it.

Are you working on it right now?
Since there have been a lot of work since yo get
the branch I would suggest you to do a fresh
CVS HEAD checkout and try to merge your previous work
on this new checkout.

Tell me what you want to do and we will collaborate on this.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Sat 08 Nov 2008 03:47:02 PM UTC, comment #32: 

Hi Eric,

do you already work on that topic? I've reviewed your last cvs
checkins and I've oticed that you work on Interaction and
objects.

Christian Stenzel <approx>
Project Member
Mon 01 Sep 2008 02:50:31 PM UTC, comment #31: 

Hi Eric,

please send me that French docs, perhaps it will help.

I can read French, only my spoken French is horrible :).

Christian

Christian Stenzel <approx>
Project Member
Mon 01 Sep 2008 11:16:12 AM UTC, comment #30: 

> sorry that I have to disappoint you.


No you don't :=)

> But in the last weeks I mainly worked at a
> publication in English, that consumed all my time.


Good to ear that, PhD student must publish their work.

> Before the mid-September I really cannot resume my
> implementations.


I understand taht too, I will come back to you
when we have a CERTI library which fullfills your need.

> Here we need an easy interface/data structure to get all
> federates which subscribed and/or publicated interaction classes
> and their parameters and attribute classes and their
> attribute values respectively. Thereby, it must be dealed
> with care attention of inheritance relationship.


OK I see. We (may be I)  should do that work.
We do not have such interface currently because
the broadcast/multicast mechanism used to send
messages to subscriber is done in another way.

I'll try to send you a report about the algorithm
used, however I think it is written in french.

Do you read french?
(We need more english documentation anyway but it
 may be faster to forward you the current french report)

And don't worry, about "pausing" CERTI devel,
we all know that Open Source development goes that way
unless some of us get paid for doing OSS dev :=)

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Mon 01 Sep 2008 09:59:02 AM UTC, comment #29: 

Hi Eric,

sorry that I have to disappoint you.

But in the last weeks I mainly worked at a
publication in English, that consumed all my time.

Before the mid-September I really cannot resume my
implementations.

As I said, the problem is not as easy as it seemed at
first.

Perhaps we can divide it in smaller parts.

The main problem for me is the part implemented in the CERTI
library.

Here we need an easy interface/data structure to get all
federates which subscribed and/or publicated interaction classes
and their parameters and attribute classes and their
attribute values respectively. Thereby, it must be dealed
with care attention of inheritance relationship.

My first idea was to implement a graph organized as tree
containing the federate id and subscribed and publicated
items as vertices. So we could hopefully determine federates which have to be informed.

But I'm afraid that this need fundamental changes with the
CERTI library (and parser etc.).

But probably someone who knows the code better than me have
also a better solutions for my problem.

Christian Stenzel <approx>
Project Member
Thu 28 Aug 2008 11:07:59 AM UTC, comment #28: 

Hi Christian,

How does your work on notif goes?
I'll try make a CERTI 3.3.1 bug fixe only release
in a week or two then I'll be happy to try to merge your
work as soon as your are ready.

I'm not pushing you, I just coming for news after
long holidays  :=)

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Tue 15 Jul 2008 07:57:39 AM UTC, comment #27: 

Hi Eric,

co works. I will use the new branch, thanks.

Christian Stenzel <approx>
Project Member
Tue 15 Jul 2008 07:02:22 AM UTC, comment #26: 

Hi Christian,

I've created a  "br_DEV_NotifServices" branch.
You may use it and commit inside the branch.
The tag exists for both "certi" and "HLA_TestsSuite"
modules.

In order to use the branch you should either relocate
you current tree to the branch using:

cd /path/to/certi
cvs update -r br_DEV_NotifServices
this may generate merges depending on the up to date
state of your tree.

or more simply get a fresh checkout of the branch:

cvs -d:ext:approx@cvs.savannah.nongnu.org:/sources/certi co -r br_DEV_NotifServices -d certi_Notif certi

(-d certi_Notif option of checkout do the checkout
 in a directory whose name in certi_Notif)

In order to check whether if you are in the "branch" version
you may use cvs stat on a file:

certi_Notif$ cvs stat README
===================================================================
File: README            Status: Up-to-date

   Working revision:    3.1
   Repository revision: 3.1     /sources/certi/certi/README,v
   Commit Identifier:   (none)
   Sticky Tag:          br_DEV_NotifServices (branch: 3.1.8)
   Sticky Date:         (none)
   Sticky Options:      (none)
certi_Notif$

as you can see the file now has a "sticky" tag of the branch.
Once you are on the branch, your commit will go to the branch.

If you want to report uncommited changes from your current
CVS tree to the new checked-out tree (in the case you did
a fresh checkout) then you may create a patch from the
first tree, and apply the patch to the new tree.

1) cd /path/to/certi
   cvs diff -u  > /tmp/tobereported.patch

2) cd /path/to/certi_Notif
   patch -p0 < /tmp/tobereported.patch

should work.

I'm on holiday on thursday so may be you can try to use the branch in the meantime such that we can fix eventual trouble
before thursday.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Mon 14 Jul 2008 11:14:23 AM UTC, comment #25: 

Yes, if you find time create that branch please.
I hope to find a working solution until the 10th
august.

I wish you nice holidays.

Christian Stenzel <approx>
Project Member
Mon 14 Jul 2008 10:58:09 AM UTC, comment #24: 

Hi Christian,

I agree with you we need a clean and complete
set of association between class hierarchy (aka ObjectClassRoot)
publishers and subscribers.

However currently the "inheritance" property with
respect to subscriber (and UAV/RAV) is handled through
a kind of recursive algorithms which will ensure
that subscribers to a leaf class are informed
of an UAV on attribute on higher (in the class hierarchy)
class.
(I'm not sure to be clear here).

I will be lacking time before I go on holiday next week
so I'll propose you prepare an appropriate patch
for your usage, and we will merge it together after
10th of august.

Is this timescale OK for you ?

If you need intermediate commit, I may create a
development branch for you such that you may commit
as you like and we will merge all or part of it
in august.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Mon 14 Jul 2008 08:36:07 AM UTC, comment #23: 

Hello,

it will be very helpful if we have such information.

One other problem which we have to handle is the
following:

Let's say we have an ObjectClassA and a derived ObjectClassB.

ObjectClassA
->ObjectClassB
-->Attribute B_1
-->Attribute B_2

The publisher of B_1 and B_2 have to be informed with a
callback startRegForObjectClass if there are subscribers
for ObjectClassA and/or ObjectClassB.

So probably the information can already extracted from the
current libCERTI. But until now I've found no
performant way.

So perhaps the introduction of new data structures can be
helpful (for ObjectClasses + Attributes and IntercationClasses
+ Attributes).

Christian Stenzel <approx>
Project Member
Fri 11 Jul 2008 10:07:18 PM UTC, comment #22: 

Christian,

I must say that I do not know this area of the code very much :=(
I'll have to analyze it before being able to answer.

Moreover I will be on holiday on 16th of July and
away from keyboard for a while.

Pierre has gone on holiday today :=(

However after a first look I would say that making
"ObjectClass::isPublisher" may be a good solution.
The thing I don't like very much is the complexity
of the resulting algorithm since
ObjectClass::isPublisher iterate over all attributes
of the class ask the attribute itself if the federate
publish it...

list<ObjectClassAttribute *>::const_iterator a ;
    for (a = attributeSet.begin(); a != attributeSet.end(); a++) {
        if ((*a)->isPublishing(the_federate))
            return true ;
    }

ObjectClassAttribute::isPublishing call STL find algorithm.
Thus you end up with 3 nested search loop (your loop + 2)
which should be very slow if one have a lot of ObjectClass
and a lot of Attribute per class...

I think that if we have to do such search this means
we should build another "map/list/..." during publish
which gives more direct access to what you need

"the list of federate publishing an attribute of the
 current object class"

one may easily build this list during publish.

I need more thought and I'm not sure to be able to
get it before holidays...

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 11 Jul 2008 07:11:50 PM UTC, comment #21: 

I'll try to answer this one later tonight.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 11 Jul 2008 02:32:48 PM UTC, comment #20: 

To your last comment: You shouldn't blame yourself let's
say this was an effect called Murphys Law :).

But now I suppose I need some help. LibCerti and
especially the ObjectClass hierarchy is not so easy to understand.

My aim was the following:

I want to send a callback startRegistrationForObjectClass as fast
as possible to the publishing Federates.
So I figured out
RTIG/Federation::subscribeObject (FederateHandle federate,
              ObjectClassHandle object,
              std::vector <AttributeHandle> &attributes,
              UShort list_size)

as my entry method.

Here I like to do the following:

  // cycle through all federates and test if it is an
  // publisher of the ObjectClass with the handle object

  for (FederateList::iterator j = federates.begin();
       j != federates.end(); ++j) {
        ObjectClass* test = root->getObjectClass(object);
       if (test->isFederatePublisher(j->getHandle()) {
          // execute cb startRegForObjClass
       }
  }

My problems are:
isFederatePublisher is a private method of the class ObjectClass.
So it can not be accessed in that way. Can or should I make that
method public?

Is that approach a good one? Are there better approches, perhaps
on a different level. For example the callback can be executed
somewhere in the ObjectClass* classes.

Are there already methods telling me which object classes a
federate currently publishes or subsribes.

Christian Stenzel <approx>
Project Member
Fri 11 Jul 2008 06:12:57 AM UTC, comment #19: 

Christian,

I saw you did commit with the 2 changes I requested.
I did change NetworkMessage.hh because you did
LAST,
SET_CLASS_RELEVANCE_ADVISORY_SWITCH
}

and I should blame me, since I asked to extend the enum
"at the end", however I should have said
"just before LAST" so I did change and commit:
SET_CLASS_RELEVANCE_ADVISORY_SWITCH,
LAST
}

in fact LAST is the only exception (I hope not to forget another one) to my preceding rule.
LAST is not a "real message"
LAST is used to control message type range in expression like:

assert(type_msg > 0 && type_msg < NetworkMessage::LAST);

so LAST should be very last value of the enum.
Sorry about that I should have explain the whole thing....

Please update your CVS tree before such assert brings
you up "new" bug.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 10 Jul 2008 05:48:16 PM UTC, comment #18: 

Hi Christian,

2 remarks:

  - you have some spurious copy/paste comment
    in NM_Classes.hh concerning the new msg

 

  - when you add a message you'd rather extend
    the enumeration at the end because if you insert
    a value "in the middle" as you did
    a mismatch in RTIA/RTIG version
    (if a user runs an older RTIG against a new RTIA+Federate)
    will generate a bug that would be harder to track
    [in fact we should add a version check initial message
     in RTIA constructor but in the meantime...]

Try to make this 2 small changes and commit your changes.
I'm OK with this.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 10 Jul 2008 02:49:58 PM UTC, comment #17: 

Hello,

here's the second small patch.

enable/disableClassRelevanceAdvisorySwitch
methods are now forwarded to RTIG.

At next, a patch with the corresponding callbacks will follow.

(file #16094)

Christian Stenzel <approx>
Project Member
Wed 09 Jul 2008 02:31:46 PM UTC, comment #16: 

I've see that Eric assigned the related bug to this task.

As I've already described below I want to start within
Declaration Management and the switch Class Relevance Advisory Switch.

It is enabled by default. To disable the switch we need
the method disableClassRelevanceAdvisorySwitch. To re-enable
the switch the method enableClassRelevanceAdvisroySwitch is
required.

A publisher of an object class gets the callback
startRegistrationForObjectClass if there are any new subscribers
(if CRA switch is enabled)

If there are no more subscribers a publisher gets the callback
stopRegistrationForObjectClass (if CRA switch is enabled).

I will put a first test federate (test_NotificationServices)
in the HLA-Testsuite folder.
I'd like the approach announced by Eric only to have one
file for the special test cases for the whole federation
(like parallel programming :)). This test federate will grow
with the implementation status of this task.

Christian Stenzel <approx>
Project Member
Wed 09 Jul 2008 02:01:30 PM UTC, comment #15: 

Hello Eric,

I will write a test federate and put it in the
HLA_TestSuite Folder.

The current state of this task is only a first
step.

Christian Stenzel <approx>
Project Member
Wed 09 Jul 2008 01:53:01 PM UTC, comment #14: 

Your patch seems OK to.
It does not seem to exhibit regression
since billard, tutorial and HLA_TestSuite runs OK.
I have just applied it to the current CVS.
however next time you may apply the patch yourself
just after review.

I have a question, how will you test those new
services?

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 09 Jul 2008 10:37:24 AM UTC, comment #13: 

I'll have a look at the beginning of the afternoon.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 09 Jul 2008 09:05:29 AM UTC, comment #12: 

Hello Eric,

here's a first small patch preparing RTIA for further
refinements.

Please have a look and if you like apply the patch.

I want to save my work.

(file #16084)

Christian Stenzel <approx>
Project Member
Thu 03 Jul 2008 11:56:00 AM UTC, comment #11: 

Hi,

a small note:

The methods for the different switches belong
to the Types and Ancillary Services in the
programmers guide.

I will put the CRA and the IRA switches to declaration
management and ARA and ASA switch to object management
(e.g. enableClassAdvisorySwitch in RTIA/DelarationMangement.*
 and enableAttributeScopeAdvisorySwitch to RTIA/ObjectManagement.*).

The distinction is based on the assignment of the
federate services within the programmers guide.

Christian Stenzel <approx>
Project Member
Thu 03 Jul 2008 07:44:38 AM UTC, comment #10: 

Thanks Eric.
I've obviously forgotten the switch
Attribute Scope Advisory Switch 
+ methods
enableAttributeScopeAdvisorySwitch(),
disableAttributeScopeAdvisorySwitch()
+ callbacks
attributesInScope(),
attributesOutOfScope()

Christian Stenzel <approx>
Project Member
Wed 02 Jul 2008 02:11:35 PM UTC, comment #9: 

Nice workplan Christian :=)

May be you can open a bug/feature request for
each step, then attach corresponding patch to the tracker
item.

This way we may track modification and test them more easily.

For example this one already exists:
https://savannah.nongnu.org/bugs/?23471

Another advice for smooth integration would be to
add an HLA_TestsSuite test case for each added feature.

These are only advices do as you can, we will help you
to integrate those missing feature in CERTI.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 02 Jul 2008 12:30:12 PM UTC, comment #8: 

Hi,

this task a bit more complex. So I describe the necessary
"to-do" steps:

At first we need some more switches and enable/disable methods:

This are:
enableClassRelevanceAdvisorySwitch(), enabled by default
disableClassRelevanceAdvisorySwitch

enableInteractionRelevanceAdvisorySwitch(), enabled by default
disableInteractionRelevanceAdvisorySwitch

and

enableAttributeRelevanceAdvisroySwitch(), disabled by default
disableAttributeRelevanceAdvisorySwitch().

The ECRA switch is used to notify a federate in changes of
object-class registration relevance.

If the ECRA switch is set, the publisher of an object class gets the callback
startRegistrationForObjectClass()
if there is a subscribtion of another federate. The callback
stopRegistrationForObjectClass()
is invoked when there are no more active subscribers.

The EIRA switch is used to notify a federate of changes in the
interaction-class relevance.

If the EIRA switch is set, the publisher is informed through the
callback
turnInteractionsOn()
when tehre are active subscribers. If there
are no active subscribers the callback
turnInteractionsOff()
is invoked.

The EARA switch is used to inform the publisher of changes in
attribute-instance update relevance.
Same as above for attributes. The callbacks are
turnUpdatesOnForObjectInstance()
turnUpdatesOffForObjectInstance()

Hope that I get all points. My plan is to create several patches.
The first patch will add ECRA switch with the enable/disable methods plus the callbacks startRegistrationForObjectClass and
stopregistrationForObjectClass.
The second patch will deal with EIRA and corresponding methods and callbacks, the last patch with EARA ... .

This is my roadmap. The work will start soon ... .

Christian Stenzel <approx>
Project Member
Mon 26 May 2008 11:25:41 AM UTC, comment #7: 

Hi Christian,
No problem, I'll wait:=)

In the meantime, JYR will probably
do some work on messages in order to
get rid of the size limit both in Message and UAV.

Have a nice Automatica show :=)

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Mon 26 May 2008 11:17:45 AM UTC, comment #6: 

Hello Eric,

I will start with this task in aprox. 2 weeks. AT time we prepare
a booth for the Automatica in Munich (a robot application) so
I've no further time for programming additional stuff.

Perhaps after that, we can talk again about the "message
refactoring".

So long,
Christian

Christian Stenzel <approx>
Project Member
Mon 12 May 2008 12:27:10 PM UTC, comment #5: 

Yes I think we may factorize out many
messages machinery into the BasicMessage class
from which both NetworkMessage and Message inherit.

The "common" field getter/setter of NetworkMessage
and Message may well be putted in BasicMessage.

Concerning Message class refactoring I know that Jean-Yves
was planning to do it, I'll check with him.
However do not underestimate the task, there is something
like 100+ more Message type... and even
if some change are "scriptable" the task may take
some day to be completed.

I'll open a special task for this "Message refactoring"

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Sun 11 May 2008 02:14:16 PM UTC, comment #4: 

Or perhaps better, we should implement a general
message class. NetwokMessages and RTIA<->Federate Messages
will than be inherited.

A first proposal ;)

Christian Stenzel <approx>
Project Member
Sun 11 May 2008 02:09:43 PM UTC, comment #3: 

Okay,

to piont 1):

Yes I will checkout the changes. Normally I'm up to date
with the current cvs. The last time was a slip-up :).

And yes, data encapsulation is always a good practice ;).

to 2):

Okay, I will think about some proposals.

>>Make Message (RTIA<->Federate) class
>>more "object-oriented" and throw
>>up most switches. Just like we did with
>>NetworkMessage


I think, that your NetworkMessage class can serve as pattern
for the Message interface. If you like, I could do that work.

I would take your NetworkMessage Code as example.

Christian Stenzel <approx>
Project Member
Fri 09 May 2008 08:46:00 PM UTC, comment #2: 

Go ahead Christian,
However I have 2 recommandations:

1) I did commit some change to NetworkMessage
   in order to make more field private
   in order to enforce getter/setter usage
   Most notably for:
        - date
        - tag
        - label

   Please update before beginning your work.

2) As a general concern if you encounter
   portion of the code that you think needs
   more "global" rework beside the current feature
   under development do not hesitate to submit
   your opinion.

   Current part which needs work are:
       - Replace PrettyDebug with a clean
         logger interface (I may be doing this)
       - Uniformize exception handling
         (JYR has begun this task)
       - Make Message (RTIA<->Federate) class
         more "object-oriented" and throw
         up most switches. Just like we did with
         NetworkMessage

  What I mean is not to begin global rework while
  implementing a feature but think about it and
  submit your idea.

 

  CERTI code base is old and some part of the code
  NEED rework/redesign we know it.
  When we have clear idea and time to do it we will
  do the job.

I'll discuss more about this on the ML.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 09 May 2008 07:15:40 AM UTC, comment #1: 

I would like to do it.

Christian Stenzel <approx>
Project Member
Tue 15 May 2007 02:05:53 PM UTC, original submission:  

The service should signal a federate that he needs
to declare its (already published) object instance
or send interaction since another federate did
subscribe to the corresponding service.

Concerned API:
startRegistrationForObjectClass
stopRegistrationForObjectClass
turnInteractionsOn
turnInteractionsOff

Eric NOULARD <erk>
Project AdministratorIn charge of this item.

 

Attached Files
file #17856:  startRegForObjClass2.diff added by approx (19KiB - text/x-patch)
file #17819:  startRegForObjClass.diff added by approx (19KiB - text/x-patch)
file #17072:  notif.patch added by approx (7KiB - text/x-diff)
file #16892:  build_doc.png added by erk (72KiB - image/png - cmake-gui screenshot)
file #16884:  switch_tested.patch added by approx (48KiB - text/x-diff)
file #16094:  switch.patch2 added by approx (7KiB - application/octet-stream)
file #16084:  switch1.patch added by approx (18KiB - text/x-patch)

 

Carbon-Copy List
  • -email is unavailable- added by gotthardp (Posted a comment)
  • -email is unavailable- added by erk
  • -email is unavailable- added by erk
  • -email is unavailable- added by erk (May be interested in looking at this)
  • -email is unavailable- added by erk (May be interested in looking at this)
  • -email is unavailable- added by approx (Posted a comment)
  • -email is unavailable- added by erk (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-01-04 erk Assigned toapprox => erk
    2011-09-28 erk Dependencies- => patch #7625 is dependent
    2010-11-11 erk Percent Complete0% => 60%
    2010-04-10 erk Dependencies- => bugs #29453 is dependent
    2009-04-03 approx Attached File- => Added startRegForObjClass2.diff, #17856
    2009-04-02 erk Dependencies- => Depends on bugs #26067
    2009-04-01 erk Carbon-Copy- => Added siron
        Carbon-Copy- => Added gotthardp
    2009-03-27 approx Attached File- => Added startRegForObjClass.diff, #17819
    2008-12-15 approx Attached File- => Added notif.patch, #17072
    2008-12-15 approx Attached File- => Added startRegForObjectClass.patch, #17069
    2008-11-21 erk Attached File- => Added build_doc.png, #16892
    2008-11-21 approx Attached File- => Added addsomedoxygencomments.patch, #16891
    2008-11-20 approx StatusDesign => In Progress
    2008-11-20 approx Attached File#16881 => Removed
    2008-11-20 approx Attached File#16881 => Removed
    2008-11-20 approx Attached File#16882 => Removed
    2008-11-20 approx Attached File- => Added switch_tested.patch, #16884
    2008-11-20 approx Attached File- => Added switch_morecorrect.patch, #16882
    2008-11-20 approx Attached File- => Added switch.patch, #16881
    2008-07-10 approx Attached File- => Added switch.patch2, #16094
    2008-07-09 erk Dependencies- => Depends on bugs #23471
    2008-07-09 erk Carbon-Copy- => Added patricecarle
        Carbon-Copy- => Added nhuynh
    2008-07-09 approx Attached File- => Added switch1.patch, #16084

    Back to the top


    Powered by Savane 3.5