Roy, If you run the Python servers under WSGI it should be fairly easy to write a custom dispatcher that will do anything you need. You could also run the Java Servlet requests through your WSGI dispatcher using something like Paste proxy. -Phil --- Roy Mendelssohn <address@hidden> wrote: > > Date: Mon, 27 Nov 2006 17:43:43 -0800 > To: address@hidden > From: "Roy Mendelssohn" <address@hidden> > Subject: Combining THREDDS and Pydap services > CC: "Roberto De Almeida" <address@hidden>, > address@hidden, > address@hidden > > I apologize for the double post. I got my mail > lists confused (old > age is setting in), I originally posted to > support-thredds but meant > to post it here. > > -Roy M. > > > Hi: > > I am throwing out to the list a THREDDS related > server problem that > we are trying to figure out relatively clean ways to > solve, in the > hope that others may have some good ideas on how to > accomplish this. > > We are heavily invested in THREDDS > (http://oceanwatch.pfeg.noaa.gov/thredds/catalog.html) > in particular > the cataloging and the data aggregation. Most of > the links on that > page are not single files but many files (sometimes > in the > thousands) being aggregated through time. This is a > very useful > feature for the type of data we have. > > Also, on an in-house server we have been testing > Roberto De Almeida's > pydap implementation of OPeNDAP > (http://pydap.org/). This server > has a lot of nice features that we are interested > in, such as his wms > service and kml service from an OPeNDAP URL type > expression. > > So what is the issue. Clearly, on web pages that > are developed in > house, where a user just clicks on a link, if we > have both Pydap and > THREDDS running on the same machine, we can change > the links to point > to the appropriate server. But for the more general > public, or for > people using the links in scripts etc, we would like > to have just one > basic link that depending on the file ending would > go to the correct > place. > > So right now if I wanted the second time period, > full extent of one > of the files the URL would be: > > http://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/AT/ssta/1day?ATssta[1:1:1][0:1:0][0:1:2320][0:1:3200] > > If I wanted an ascii file it would be: > > http://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/AT/ssta/1day.ascii?ATssta[1:1:1][0:1:0][0:1:2320][0:1:3200] > > but what I would like to do is that if I give it: > > http://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/AT/ssta/1day.kml?0:1:2320][0:1:3200] > > and it would know to switch-over to the pydap server > and produce the > kml output (while still being able to view the file > as a single file > through the THREDDS aggregation). > > Now as given, it is unlikely to work since THREDDS > is in the URL. > But suppose we had something like: > > http://oceanwatch.pfeg.noaa.gov/ERD_Data/satellite/AT/ssta/1day.ascii?ATssta[1:1:1][0:1:0][0:1:2320][0:1:3200] > > or > > http://oceanwatch.pfeg.noaa.gov/ERD_Data/satellite/AT/ssta/1day.kmlATssta[1:1:1][0:1:0][0:1:2320][0:1:3200] > > and want it so that in the ascii case it goes to > THREDDS and in the > kml case it goes to Pydap. > > Ideas we had: > > 1. Monkey with the appropriate section in the > THREDDS java to > redirect when it recognizes the new service type, > much as it does > with WCS services. Downside is we would have to > monkey with every > revision and could mess up things in unexpected ways > in the process. > > 2. At the apache or tomcat level, have the > redirection made (is this > possible?) based on file type. > > 3. Some other solution? > > A question I pose to Roberto (as he is copied) but > may be of general > interest is if there is a way for Pydap to serve > OPeNDAP served data > that is at another URL (even if on the same > machine), much as > THREDDS can. It is this that would simplify what it > would take for us > to use the aggregation capabilities in THREDDS with > Pydap in our own > internal scripts as we can still views these as one > file - or does > anyone else have general suggestions as how we might > combine the > desirable features of each. > > -Roy > -- > ********************** > "The contents of this message do not reflect any > position of the U.S. > Government or NOAA." > ********************** > Roy Mendelssohn > Supervisory Operations Research Analyst > NOAA/NMFS > Environmental Research Division > Southwest Fisheries Science Center > 1352 Lighthouse Avenue > Pacific Grove, CA 93950-2097 > > e-mail: address@hidden (Note new e-mail > address) > voice: (831)-648-9029 > fax: (831)-648-8440 > www: http://www.pfeg.noaa.gov/ > > "Old age and treachery will overcome youth and skill." Phil Sharfstein GODAE Project Manager Fleet Numerical Meteorology and Oceanography Center 7 Grace Hopper Ave, Stop 1. Monterey, CA 93943 831.656.4525 address@hidden =============================================================================== To unsubscribe thredds, visit: http://www.unidata.ucar.edu/mailing-list-delete-form.html ===============================================================================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.