🚀 go-pugleaf

In article <42200@pprg.eece.unm.edu.pprg.unm.edu>, huffman@donna.gsfc.nasa.gov (George Huffman) writes:
|> Brian - following up on our conversation, and this mail, the main barrier to
|> doing more with HDF from the Khoros viewpoint is time and $$$.  If the
|> Consortium members make it a priority it will happen; if not, it's a nice
|> idea that will accidently get done if it's easy or someone in the "community"
|> does it.  I'd guess that an interface to HDF isn't real hard for a hard-
|> core Khoros programmer, but otherwise, wading through the code would be
|> challenging.  
|> 
|> I wouldn't discount a "translator" approach; the data connections between
|> khoros programs can be implemented either as files (the default) or
|> through shared memory (mapped memory? it's the choice other than
|> "file" when you click on a connection in cantata).  So, the
|> translation program can be viewed as getting the data into memory with
|> minimal overhead for translating the header.
|> 
|> On the other hand, I exactly agree that Khoros will be more attractive
|> to NASA projects if HDF is "supported".  
|> 
|> George Huffman
|> 
|> 

|> doing more with HDF from the Khoros viewpoint is time and $$$
...is an obvious issue, but is the group aware enough as to the size of
EOS and what direct support for its 'favorite son' will mean to KHOROS?

Translators are nice and necessary but whenever I try to say to someone,
"well, we can always translate it" I get looks that I don't approve of.
I'm actually working with someone here in translating datasets. Its a fine
thing but I want the Khoros applications to work with HDF data transparently.
Even the SDSs....actually, ESPECIALLY the SDSs.

--Brian