[RFC-004]Comment-10

Organization: Instituto Oceanografico da Univ. de Sao Paulo

Dear friends,

Attending your request...

If you have experience in implementing or installing a DAP server or client we'd like to hear from you. If you have tried to implement or install a DAP server or client but abandoned the effort for whatever reason, we'd like to hear about that experience as well.

I am an oceanography professor with some computer science background (i.e. I can install a Linux distro and manage a simple web server) but very limited time - as many of you. I am currently installing a DODS server at the Oceanographic Inst. of the Univ. of Sao Paulo (IOUSP) and, in parallel, helping Dr. Paulo Nobre from the Natl. Inst. for Space Research (INPE) to choose what can became the national recommended standard for oceanographic and atmospheric data distribution. Please forgive me if I overlooked the answer is in the manuals.

The first issue is something a colleague of Dr. Nobre has pointed out a while ago. How are data transfer errors handled? For example, let's compare a ftp request and a DODS request:

I make a ftp request for a file. The server starts transmitting and suppose there is a data transmission error that would cause a ftp checksum problem. I know I got bad data because the checksum doesn't match. Now I send the DODS request for a subset of a data file. Again, suppose that there is a data transmission error. Since I'm not getting the whole file, how do I know I got junk? The next topic regards the installation procedure and manuals. I like DODS/OpenDAP because:

It's free! The concept of a cross-platform, format-independent, piece-wise data server layer is excellent. That is why I want to use it. The Java client is another very good idea. Matlab is awfully expensive in Brazil, IDL is not used by many people in my field.

The Matlab data browser is easy to use and I like it.

IMHO it can be improved because...

There are very few binary (rpm) packages. Some of these are embarrassingly outdated (Who uses RH7.3 ?!). Installation from source is time-consuming and at least in my case, prone to failure. It often fails because of a wrong library version, file location, etc. Who has the time or the tech personnel to look into this level of detail? Please make available RPMs for the latest stable kernel release. Static builds make life easier, I know they are bigger, but data servers have huge disks - no one will notice. Be sure it works on the recent releases of the most common OS/distros used for servers among earth science people (e.g.: Sun, SGI, Fedora, SUsE, Mandrake, Debian, RedHat, Slackware, Gentoo, OpenBSD etc.) People learn a lot by example. You could include more examples of data files, at least one for each server type, and tutorial web pages so that the impatient user can hack through the examples and quickly put a demo server to work. A demo server helps to sell the OpenDAP idea and that is what we all want to do, right?

DODS URLs are inherently complex. Among the examples above you could include a simple data-request parsing code, some easy to understand HTML (+ php, js, cgi) page that can assemble URLs based on input latitudes, longitudes and dates instead of raw indices.