On Mar 15, 2006, at 10:14 AM, Thomas LOUBRIEU wrote: Hi Peter,
Thanks you for you help.
We will consider the pyDAP option but we do not have any python skills in our team so we would prefer to use the Java DRDS API. That way we will be able to easily improve our server as our database or the openDAP API is updated.
Thomas,
My initial take on your question was that the pyDAP code would be easier to work with because it is so much smaller. Also, there's an outside chance that pyDAP can handle nested sequences already, which would save you from having to add features to the DRDS.
Roberto, Any comments?
Regarding the DRDS, we do plan to support it and would welcome any contributions you can make to increasing its functionality! We can answer questions and the like, but right now we're 'booked solid' on projects, so we can't do any of the coding. I'll include some more comments below...
Bye,
Thomas
Peter Cornillon wrote: Hi Thomas,
We discussed your message today. The upshot of our discussion is that you should consider pyDAP first and if that doesn't meet your needs, then the DRDS. James, Dan and Nathan each have specific comments that they will send you in reply to your message. I would however like to send it to dods-tech so that others on the e-mail list, e.g., Roberto, can also chime in. Do you have any problem with me fowarding your e-mail to the dods-tech list or would you prefer that we reply to your without posting the message? If you have no problems with airing your questions on dods-tech, either I can forward the message to the list, or you can send it to the list. Your choice.
Peter On Mar 2, 2006, at 9:43 AM, Thomas LOUBRIEU wrote: Dear Peter,
At CORIOLIS in-situ data center, we are starting to develop an opendap server directly connected on our ORACLE RDBMS which contains the full profiles (date, position, measurements...) managed by the CORIOLIS data center.
We would like to disseminate the profile datasets, as DAPPER does : a sequence of location (position + date) containing sequence of profiles (parameter list) containing sequence of measurement (for each vertical level).
Our server has to be a web application which is easy to deploy on existing tomcat server.
We're now looking for the best framework to start with :
2) DRDS ( http://www.opendap.org/download/drds_server.html) : it is a good model for us because it is easy to connect to a RDBMS but it doesn't seems to handle sequence of sequence ? We could add that function to DRDS but we would like to be sure the DRDS release will benefits of the future improvments of Java-DAP.
Nathan Potter is author of the DRDS, as well as significant part of the Java implementation of the DAP2 and supporting code. He's the real authority on the DRDS, but I'll try to give you some background and hopefully he will correct my errors.
The DRDS is designed so that there is a one-to-one correspondence between database tables and DAP datasets and only those tables that are configured to be DAP datasets are visible to outside users. That means that you have complete control over what users coming in from outside see, but also that you have to do some configuration work to serve data once the DRDS is installed in TomCat. One basic feature of the DRDS is that it does not provide a way for outside uses to perform join operations since without detailed knowledge of the database's internals it is hard to do those sorts of operations well. To join two or more tables and make them appear as a single DAP dataset, use a view. So in the end it _is_ possible to serve, as a single dataset, information stored in multiple tables, but you will have to add the appropriate view to the database. This is generally not a problem, but it's an additional configuration issue to consider.
3) With Dapper we should set up and maintain a mysql server containing information copied from our Oracle Database. Moreover, we will not benefit from the indexation of our data in Oracle (qualitiy flags, vertical levels...) to improve the performance of the request (dapper reads netCDF files).
4) Anagram seems to be a good candidate but, firstly, we are a little bit afraid because only GDS (GrADS-server) seems to be made from that framework. Secondly, we will need specific filters at the upper layer of the Anagram architecture (in order to prevent overload by counting the requested record in the database).
I believe that people at PMEL have used Anagram, too.
James
What would you recommend in our case ?
Thanks for your help,
Bye,
Thomas and Arnaud.
--
------------------------------------------------------------- Thomas LOUBRIEU IFREMER IDM/ISI BP70 29280 Plouzane FRANCE Tel.: (+33) (0)2 98 22 48 53 Fax: (+33) (0)2 98 22 46 44 -------------------------------------------------------------
-- Peter Cornillon Graduate School of Oceanography - Telephone: (401) 874-6283 University of Rhode Island - Fax: (401) 874-6728
--
-------------------------------------------------------------
Thomas LOUBRIEU
IFREMER IDM/ISI
BP70
29280 Plouzane
FRANCE
email: Thomas.Loubrieu@xxxxxxxxxx
WWW : http://www.coriolis.eu.org/cdc
Tel.: (+33) (0)2 98 22 48 53
Fax: (+33) (0)2 98 22 46 44
-------------------------------------------------------------
-- James Gallagher jgallagher at opendap.org OPeNDAP, Inc 406.723.8663
|
