Re: [Gmat-developers] Options for Handling ".Add" CapabilityforSubscribers inside Functions

[Darrel J. C. <gm...@th...>]

The issue we are trying to handle is really a scoping issue: Subscribers 
are set to have scope at the level of the Sandbox (depending on how we 
set their defaults), but we are trying to make sure that they behave in 
the most natural way possible when defined one place -- the MCS, for 
instance -- when we are in a different scope, like an FCS for the MCS 
defined Subscriber.  In the current implementation, Subscribers do not 
have information about the state of the run, so they do not know if the 
data received from the Publisher was generated in an FCS or an MCS. 
Assuming we discard options 4 and 5, we will need to make changes so 
that this state information is handled somewhere regardless of the 
option selected.

Option one is the cleanest from this perspective.  The state information 
can be handled along with the cloning required to meet the other scoping 
requirements -- if we pass the clones into the function and use the 
object pointers to identify which objects are sending data to the 
subscribers, the subscribers WILL NOT UPDATE inside of the function 
because the object pointer references a clone, and not the original 
object.  That is the cleanest approach to implement IMO, because with 
that implementation, the subscriber data list (if needed at all -- it 
may just fall out naturally for this case) is kept in the CallFunction 
that manages the function call, and does not ever need to be changed for 
the subscribers or -- heaven forbid! -- sent into the FCS.  Please spell 
out the limitations that make you object to it, so that we can discuss 
options for resolving them.  An example of something you'd like to do 
would be very useful here.

Option two is a bit more work, because it will have us doing string 
comparisons and additional mapping on the subscribers every time we 
enter a function, and then some corresponding cleanup when we leave.  In 
other words, the subscriber data list will need to be managed both in 
the CallFunction and in the Subscriber, and we'll need to do some object 
lookups every time we enter and leave a FCS to be sure that the 
subscribers are referencing the right objects in the command sequences. 
  String comparisons -- needed for these lookups in the current design 
-- are computationally expensive, so this will either add a performance 
hit, or require that we add some potentially buggy logic that could be 
difficult to maintain.  That means we'd need to very carefully comment 
the code so that when we make changes to it, the implementation is 
extremely clear, so that subsequent changes don't introduce undesired 
side effects.  In other words, that will have a schedule impact that may 
be larger than you'd like.  It is still workable; it just makes the 
system more complex.  We need to understand up front that there is an 
impact on schedule here.

Option 3 raises some issues that we'd need to discuss more thoroughly. 
I'm not sure, for instance, what the desired behavior would be for the 
legends and labels on plots and reports with this option.  It has all of 
the issues raised for option two with fewer advantages -- or at least 
less user support, as far as I can see -- so for now I'll just close my 
eyes and hope it goes away!  :-)

I do still think that our best short term option is to finish the rest 
of the design for GMAT functions, and implement that design.  We can 
then iterate on it to resolve the subscriber issues; we're not likely to 
get it exactly right the first time IMO, so we should plan to update it 
in round two.  Since it's easier to move from option one to option two, 
that's what I'd recommend: implement option one, and be ready to move to 
option two based on user feedback.  We can comment the code at the 
appropriate places, indicating where the subscriber updates need to be made.

- Darrel



Edwin Dove wrote:
> I do not want us to implement approach 1 because it's too limiting.
> 
> I'm not opposed to approach 2. We're basically relying on the user to make
> sure the names of the objects they want to plot in all control sequences
> match if they want to use Step Update mode. This could lead to the user
> incorrectly naming an object but still plotting it as though it were the
> correct one. That's fine as long as the user knows that.
> 
> Approach 4 and 5 are a big NO!
> 
> If others believe approach 2 is okay I'll update the suscribers in functions
> requirements document based on that approach.
> 
> Edwin
> 
-- 
-----------------------------------------------------------------------------------------------------
GMAT Architectural Design, Linux Development and Test Team

Darrel J. Conway, Ph.D.      Thinking Systems, Inc.
Senior Scientist and CEO     6441 N Camino Libby
Phone: (623) 298-4530        Tucson, AZ 85718
FAX:   (520) 232-2533        www.thinksysinc.com
djc_at_thinksysinc_dot_com
-----------------------------------------------------------------------------------------------------