Hi Don, thanks for the prompt reply. That's what I needed, a way for a
jnlp to refer to a bundle by url. I now create a template .xidv and a
template .jnlp file, and use Ant to replace the placeholder with the
current date's data urls. I no longer need any base64 encoding in my
script. Thanks for the link to IDV's encoder though.
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
*************************************************************
