NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
On a related note, is there any page documenting IDV's command line argument options, short of looking at the source ? Seems like a lot if useful options that most people, myself included, are not aware of.
Stuart Don Murray wrote:
Hi Stuart- Stuart Maclean wrote:About jnlp bundles referencing other bundles, can the reference be a url one, i.e. http, or it is limited to files? The nice thing about the base64 encoded bundle being bundled by value as it were is that the bundle is self-contained.Yes, it can be a URL.If I did change to a bundle reference, what arguments list should I have? Currently, and this works great, I have the regular<application-desc main-class="ucar.unidata.idv.DefaultIdv"> <argument>-nodefault</argument> <argument>-b64bundle</argument> <argument>BUNDLEHERE</argument>Well, in your example, you could either: - change -b64bundle to -bundle and change BUNDLEHERE to the URL of the .xidv file - or remove the -b64bundle line and change BUNDLEHERE to the URL of the .xidv file. Why do they both work? The -bundle argument can be used when you want to distinguish the next argument from another command line argument (i.e, if you had more you wanted to add). But, by default, the last argument on an idv command line can be a bundle file, so if you only have one argument or you just have the .xidv as the last, you don't necessarily need the -bundle line.I used a base64 encoder I found online to convert the .xidv bundle file, after I had run Ant's replace task on it to get the 'latest' urls. I then add the jnlp header and footer and this works.Unfortunately, not all base64 encoders were created equal. We ran into that at one point when we switched and now we use the org.apache.xerces.impl.dv.util.Base64.encode in the IDV's external.jar. So, if you do run into problems, you could always use that one. The base64 encoding is done in static methods in ucar.unidata.xml.XmlUtil (encode, decode) so you could always use that to be completely compatible with the IDV.What are the appropriate arguments if referencing an external .xidv bundle file? You mention %pathtobundle% as the sole argument?That was just a placeholder. You would replace %pathtobundle% with the actual path to the bundle.Two minor points, relating to opening IDV with the bundle-containing jnlp file. First is that the world coastline map is displayed, even though it was not displayed when I saved the bundle (and I doubt that my bundle editing of url paths could have affected the coastline??), and second is that the Field Selector window appears, even though I had closed it before I saved the bundle. These are no big deal, the user can easily work around them. Maybe I am expecting too much of the 'save state' feature of the IDV, which I must say is mighty impressive.The map lines is a bug which we are working on. The Field Selector state is defined by the user's preference so will be shown if that preference is set. The bundle doesn't contain the state of the window. We'll mull that one over.One last point is that I see from the jnlp trail that you an expert in the jnlp spec. When I discovered that I could specify something as heavyweight as Java3d, with its native lib, to be downloadable via jnlp, I was well pleased. Too many times I have seen jnlp delivered apps with the caveat 'you need Java3d installed'. Then I look in your jnlps and see that you have that feature too! Nice one.I wouldn't say I'm an expert and I'm sure there are probably a lot of other options that we should be using. Glad you were able to glean something from our lack of knowledge. ;-)BTW, I'll look into your suggestion of using a 'latest' data set and url referencing scheme.It's a quick and dirty solution. Let us know if you have other questions. Don ************************************************************* Don Murray UCAR Unidata Program dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm *************************************************************
idvdevelopers archives: