Mc-V Team Meeting Minutes - December 13, 2006

The McIDAS-X "listener"
Dave Parker presented the latest work on his McIDAS-X "listener"  Currently, it's designed to send image, nav, enh, stretch, and graphics as line segments.  The GUI that he presented was written in html and java script, the back end is ajax.   With this listener, "anything could use McIDAS as a service".

"What are frames?"  Frames are within the data source, IDV is time based only.  TomR though that perhaps we could treat frame numbers as time.   

"How do we handle keyins like A, B, L, or SF?"  
DaveP - We have to respect the viewing frame.   Both Mc-X and Mc-V will have to know which frame they're on. 
TomW and Gail - would like to use Mc-V for loop control and Mc-X for the image creation. 
RickK - looping with the VCR buttons is okay. 

Tom Rink "This is good because we can always get at things that Mc-X does that we might not ever do in Mc-V"

"What about web services?"
Scott - Now that we have a working prototype, what do we do now?  How do we restrict/define the pipe?  How much effort to make this a web service?  IDV is a service oriented, web service system. 
Matt - What is a web service?  Is IDV a web service?
ScottM - W3C has a definition for a web service....
TomW - IDV is not embracing the formal W3C definitions.  However, most data is extracting to a level that conforms to W3C (e.g. THREADS)
Matt - worried that our community won't fit the mold
Scott - we're trying to be leaders in science, in computing, and we need to leverage some of the other work out there. 
DaveP - remember that this is more of a replacement for X-windows, not how Mc-V works with all other applications
TomW - one reason NOT to do web services.  Right now, things are easy to install by non-administrators. 
ScottM - this needs a list of requirements (what Mc-V needs from Mc-X, and what Mc-X needs from Mc-V)
TomW - that should be done in a small group, which will meet separately

Why Port 80?
TomW - For example, on some military bases, they are very limited on which ports will be opened to the outside world, if any.
DaveP - Any port will work.

EVOLUTION, NOT AN END GOAL
Matt - remember that this is EVOLUTION, NOT AN END GOAL   This meets the short-term goals of
1 - MUG needs a new GUI, and 2 - Mc-V needs a way to talk to Mc-X
GailD - the basics need to be hashed out now, but the functionality can evolve.

"Not just a pretty picture"
Rick - the IDV has neat tools (e.g. transect).   We should use the IDV capabilities, even if it's to do what Mc-X can do.  It should not be just a pretty picture.   There should be data.
TomW - the IDV knows the data AND the ADDE request.  Maybe there's a way for it go get the data if it needs to do so.  Maybe write Mc-V code that can access the frame directory.
One problem, the server hit - local data may require a remote server set-up
DaveS - What about interactive Mc-X commands?   answer - those won't be done in this bridge, but we do need to address the functionality of those commands in Mc-V.
TomW - ADDE servers will be here "forever".  And remember ADDE servers written in JAVA can still be ADDE servers.
DaveP - Mc-X is a background data source.

Requirements Documents
ScottM - What's the next step?   How do we get it documented so others understand?   Requirements within our own group.  Requirements for other PIs.  TESTABLE DOCUMENT - protocol and IDV requirements.


Scripting Language for Mc-V
Kathy - We need to make sure that we're doing the right thing.  Why the IDV-specific ISL and not something others are using?   Python does not have the syntax to create the scripts.

Bruce - ISL is NOT a scripting language.  It is a description of how to setup the IDV. 

Kathy - this problem is not unique to this project.  Mixing Unix and Mc-X commands in a script is the REAL POWER of Mc-X.  We need to use a scripting language that is known in the community. 

TomW - something that should be added to the steering committee list is that we need to be able to send a message to an active session, start IDV without a display, do ISL commands, and end up with the output display.
Kathy - It is a requirement!
Becky - It's already on the priority list.  I just don't think we've done any real work on the topic.
TomW - we need to have a separate meeting and start discussing the needs of the user and the right way for Mc-V to handle this.  Maybe we need to embrace our own scripting language, not necessarily ISL.

ScottM - Why IDV and not Matlab or IDL or something else?  
TomW - Java, VisAD, IDV is open source, platform independent.  IDL and Matlab are proprietary and very expensive. 

Dee - Still wondering if IDV is the right direction.   We need an ability to do scripting in the background, or else IDV is not the answer.  It's that important. 

TomW - every script that Kathy has should be turned into a bundle.


ScottM - REQUIREMENTS LIST
    - listener protocol
    - scripting language

If the IDV/VisAD part is open source, why will people pay for support?