[hyades-dev] RE: [YOUR ACTION REQUIRED] Discussion points from Tuesday's

[Antony.Miguel@xxxxxxxxxxxxx]

2) "Publishing".  In reviewing the sequence diagram that Kris presented 
for
"run and monitor a single test", it became clear that we need to provide 
a
way to engage monitoring before the test is actually "launched", or else 
we
would have a race condition trying to start up the 
IRemoteHyadesComponent to
monitor the test.  It was suggested that we should split up the launch()
method of IExecutor into two methods, one of which "publishes" 
(instantiates
the actual remote components), and another that actually invokes the
IExecutableObject.  Thoughts?

I may be missing something here but is there some reason we can't just 
call startMonitoring() before we call launch()?

3) Factory pattern.  While the use of the factory pattern seems 
desirable,
it looks rather inelegant that we are creating objects with a factory 
and
then adding them as children of a IExecutionComponent.  In thinking 
about
this more, I think the factory pattern may still be a good approach, 
because
we'll need an extensibility point for creating alternative 
implementations
of IExecutor and IRemoteHyadesComponent.  Registering with a factory 
seems
like a reasonable way to accomplish this.  Thoughts?

I think that although the factory seems a little inelegant in the simple 
usecases we have so far it will prove itself in the implementation of 
the design.  I'm happy to keep the factory in.

4) Semantic of IExecutableObject.getChildren().  We agreed that
IExecutableObject.getChildren() would only retrieve the direct children 
of
the IExecutableObject on which it was invoked.  We also agreed that it 
may
be worthwhile to expose an additional API to walk the tree and retrieve 
all
of the children, although a client could obviously implement their own
traversal.  Thoughts?

As far as I can see, any extra API we expose for the purpose of getting 
all children would be there purely for optimisation (and possibly 
convenience) since getChildren() is capable of giving us all the 
information there is - including heirarchy information.

This optimisation is only useful when the tree structure needs to be 
obtained quickly or frequently.  I imagine that in most cases the client 
would build up a picture of the tree from the getChildren() calls before 
they are launched anyway.

Based on this I would think it would be an optimsation of little use.  I 
would recommend we leave it as just getChildren() for now.  This also 
saves us deciding on some tree structure to represent the nodes.


cheers

Antony