Currently all HDS products are grouped simply under unidata.binaries.hds, but it would be easy to determine, for example, a model name from the product header and post products to newgroups named respectively, such as unidata.binaries.hds.ruc.
This past fall it was noticed that while encoded size for the CRAFT data fell mostly in the range of 1% - 7% increase, some, but not all, encoded CONDUIT products had increases in size of up to 100%. It was determined that this occurred on CONDUIT products having nearly all null characters, which is one of the few characters that must be encoded. Thus, various simple encoding modifications were tested in attempt to mitigate this problem. Testing occurred over both the CONDUIT and the CRAFT feed types so that an improvement in one would not make the other worse. It was found that adding 207 to every byte before encoding gave the smallest number of encoded characters for both feed types, giving an average number of encoded characters of 1.17% for CONDUIT data and 1.66% for CRAFT data.
Since NLDM is a package that sits on top of INN, it is intended that NLDM code will exist in a subdirectory of INN. Users will get INN from its distributor* and get NLDM from Unidata. Each is to be built and installed separately.
(* INN is distributed by ISC, recently renamed from the Internet Software
Consortium to be Internet Systems Consortium, Inc.)
The CRAFT data is being posted to newsgroups based on station ID, e.g.
unidata.binaries.craft.KABC. So far there are over 100 craft newsgroups,
one per station for each station reporting.
The JNLDM GUI has undergone significant conceptual and visual modifications, along with a complete rewrite of the code. The new GUI is more attractive and more intuitive. It is now broken down into four distinct categories: Console, Data Transfer, Logging, and DataFlow. There is one screen devoted to each category. Wizards exist to help new users find their way around, and an extensive amount of error checking is performed to make the GUI as safe to use as possible. Because the GUI only exists to modify the configuration file, and does not interact with the program directly - except to display possible warning and error message generated by the Logger - its code has been completely separated from the code for the back end of the program, making the GUI easier to modify and maintain.
JNLDM file caching was completed. Upon shut down articles are now being stored to disk and are read back into memory when the program restarts.
JNLDM was integrated with the IDV so that the IDV could display level II radar data received by JNLDM. The design of this initial integration effort was made intentionally simple. An instantiation mechanism was provided so that JNLDM could be a class, called RadarControl, to be instantiated by the IDV. The RadarControl object maintains a list of stations of interest and notifies the IDV when products arrive from any of these stations. Methods for that class include addStation and removeStation.
(Since it is not yet possible to modify a JNLDM subscription, the underlying implementation of the above has JNLDM getting all level II radar data and only notifying the IDV of the arrival of products of interest. Yes, this is inefficient.)
Also, a new action, IDVAction was added to JNLDM to allow it to notify the IDV of new products. In order to provide the data in its original raw format, it was also necessary to write Java code to concatenate level II radar products into a single volume and to unbzip2 the data. These tasks are part of the IDVAction.
This simple integration method worked - the IDV was able to display level II radar data at its time of arrival.
Additionally, a scour utility was written in Java to keep disk space from filling up.
Significant effort has been put into JNLDM documentation in the form
of textual descriptions for developers, javadocs, and flow diagrams.
Mike has completed developer documentation and a user's manual.
Control messages are handled by an INN program called controlchan.
controlchan allows a local site to handle the control message in a variety
of ways:
This feature was tested by creating messages to notify a site of
both new groups and groups to be deleted. The appropriate file
of known newsgroups was indeed successfully updated.
This mechanism may also be useful for sending or pulling data, but this
remains to be tested.
Consider a scenario where site A relays articles to site B. Site B wishes to change its subscription list that resides at site A.
First it is necessary to install a new user 'gup' at site A.
Also must will be a small file structure on site A to handle the subscription
changes, structured as follows:
sites/
siteB/
groups (current subscription list)
groups.old
exclude (groups site B is not allowed to receive)
log (of operations performed for site B)
siteX/
siteY/
siteZ/
The gup account at site A must have .forward file that includes a command to pipe the email to the gup program. When a user from site B sends a request for a subscription change to gup@siteA, gup will first check the active file of user 'news' to ensure that news knows about the requested newsgroups. It will then update the appropriate groups file in the subdirectory for site B.
Testing showed the GUP indeed performed the above. However, that
alone is not sufficient to change the appropriate configuration file, thus
a critical step is missing. It is not yet clear how this
could be handled.