From brideout at haystack.mit.edu Thu Jan 27 11:42:12 2005 From: brideout at haystack.mit.edu (William Rideout) Date: Mon Oct 23 17:53:07 2006 Subject: [OpenMadrigal-developers] Suggestion for Madrigal user data Message-ID: <41F919E4.6080304@haystack.mit.edu> Suggestion by Ingemar H?ggstr?m at Eiscat: ******************************** One thing that we have came across is that users have downloaded faulty data, which we then have replaced. But, we don't know whom to tell (that the data was wrong) about it. So, maybe one could add something to the notes file, whenever someone downloads data. IP number and ask for name and email address should be enough. Then, one also get a record how many is using the data... I guess one would allow for dummy names/email, but then it's not our "fault" if they work with bad data.. ******************************** Bill Rideout commentary: This situation could also apply to data that is reprocessed using an improved algorithm, not just to the case of the original data being faulty. This could be accomplished by requiring the user to fill out this information in a form each time they enter a Madrigal site. A second option is to use the same approach that Madrigal now uses to store user filter information. To save a filter, a user creates a login that does not require any permission. That login is meant for identification only, so security is not an issue. This login is saved as a cookie on their browser, so they never need to login again unless they change browsers or computers. As Ingemar says, this doesn't guard against dummy information, but in that case they simply don't receive this update information. A third option is to simply make the second approach optional - there would be a line at the top that says something like, "If you'd like to be notified whenever a dataset you examine is updated, please login here". If the user was already logged in, the line would say "You will be notified if any dataset you examine is later updated." Any thoughts? Bill -- Bill Rideout MIT Haystack Observatory Email: brideout@haystack.mit.edu Phone: 781 981-5624 From jmh at haystack.mit.edu Thu Jan 27 11:56:22 2005 From: jmh at haystack.mit.edu (John Holt) Date: Mon Oct 23 17:53:07 2006 Subject: [OpenMadrigal-developers] Suggestion for Madrigal user data Message-ID: <200501271656.j0RGuL0o010958@chaos.haystack.mit.edu> I much prefer the third approach, that is optional login. John ________________________________________________________________________ | | | John M. Holt tel: 781-981-5625 | | Principal Research Scientist fax: 781-981-5766 | | MIT Haystack Observatory email: jmh@haystack.mit.edu | | Route 40 WWW: http://www.haystack.edu/ | | Westford, MA 01886 | | USA | |________________ Ni h-eibhneas gan chlainn domhnaill _________________| From shunrong at haystack.mit.edu Thu Jan 27 17:29:35 2005 From: shunrong at haystack.mit.edu (Shun-Rong Zhang) Date: Mon Oct 23 17:53:07 2006 Subject: [OpenMadrigal-developers] Suggestion for Madrigal user data In-Reply-To: <200501271656.j0RGuL0o010958@chaos.haystack.mit.edu> References: <200501271656.j0RGuL0o010958@chaos.haystack.mit.edu> Message-ID: <41F96B4F.9000403@haystack.mit.edu> I prefer the third approach too as John. When people are just browsering around the data (not have decided whether they will eventually use them), they won't like to "register" or login. But when they are more serious about the data, I think they will. Other than name / email /affiliation, we should save the madrigal file name used, so that when it's updated the specific user can be notified. It might be useful to provid an option for those who are interested in general Madrigal news, such as new data release and data update, software update, etc. to receive email notices. This might be a way to build an user bank which our funding agency may be happy to see. Shunrong From byrnes at bu.edu Fri Jan 28 00:01:48 2005 From: byrnes at bu.edu (John Byrnes) Date: Mon Oct 23 17:53:08 2006 Subject: [OpenMadrigal-developers] Python Distutils Message-ID: Hello all, I wanted to suggest that the setupMadrigalWeb.py file be renamed to setup.py and a separate README be included with the remotePythonAPI distribution. This better facilitates the use of distutils for building packages (RPM, wininstaller, etc.). IIRC, trying to build an RPM fails when the setup script isn't named setup.py . Also, including a binary of the pnet library for Mac OSX on PPC with the Matlab API would be nice. I can provide the file if you wish. Regards, John -- John Byrnes Graduate Student ECE Department Boston University byrnes@bu.edu From sschrade at uos.de Fri Jan 28 05:38:45 2005 From: sschrade at uos.de (Steffen Schrader) Date: Mon Oct 23 17:53:08 2006 Subject: [OpenMadrigal-developers] Mailservice Message-ID: <1191.131.173.8.138.1106908725.squirrel@webmail.rz.uni-osnabrueck.de> Good morning! I generated yesterday some searches and the "server" returned to me that I will get a mail with an url were I can find my requested data. I didn`t get a mail so fare. How can that be, did I made a mistake? Many greatings an with best regards Steffen Schrader University of Osnabr?ck Germany From brideout at haystack.mit.edu Fri Jan 28 09:19:33 2005 From: brideout at haystack.mit.edu (William Rideout) Date: Mon Oct 23 17:53:08 2006 Subject: [OpenMadrigal-developers] Mailservice In-Reply-To: <1191.131.173.8.138.1106908725.squirrel@webmail.rz.uni-osnabrueck.de> References: <1191.131.173.8.138.1106908725.squirrel@webmail.rz.uni-osnabrueck.de> Message-ID: <41FA49F5.8080302@haystack.mit.edu> Steffen, As you may have noticed on our Global Search page, we have two different options for searching. By default "Search local Madrigal site" is selected. Madrigal is a distributed database, which means each site (Eiscat, Millstone Hill, SRI, etc.) has their own database that contain data from their own instruments, but these databases share high-level information. So if you are on the Eiscat Madrigal site, "Search local Madrigal site" means you will search the entire Eiscat Madrigal database. If you choose this option, a fast search will occur on the local site to see if it has any experiment files that match your criteria, and you will get a fast (less than one minute) message telling you whether any experiments were found, and if so, an estimate of the time needed to analyze them for the data you requested. If no experiments were found, you will be told that, and then redirected to the global search page to alter your criteria, if desired. If no experiments were found, you will not receive an email with results. The second option, "Search all Madrigal sites", allows you to run that same search on every Madrigal site at once. That's fine if you want world-wide data, but it has one disadvantage: the software is not written to know whether any valid experiments exist in a timely manner. So its very possible not to get any emails back. This Madrigal-wide search option is new, and so that lack of feedback is certainly something that could be improved. Here's what I recommend to search for Eiscat data: Go directly to the Eiscat site at http://www.eiscat.com/madrigal/. Click on Access Data -> Global Report, and leave "Search local Madrigal site". All Eiscat data is local there anyway. Then when hit submit you should get immediate (less than one minute) feedback as to whether any experiments were found. If experiments are found, you should get an email within the time estimated. If you don't, I'll just have to put on my cross-country skis and visit my friends in Scandinavia. Bill Steffen Schrader wrote: > Good morning! > I generated yesterday some searches and the "server" returned to me that I > will get a mail with an url were I can find my requested data. > I didn`t get a mail so fare. How can that be, did I made a mistake? > > Many greatings an with best regards > > Steffen Schrader > University of Osnabr?ck > Germany > _______________________________________________ > OpenMadrigal-developers mailing list > OpenMadrigal-developers@openmadrigal.org > http://www.openmadrigal.org/mailman/listinfo/openmadrigal-developers > -- Bill Rideout MIT Haystack Observatory Email: brideout@haystack.mit.edu Phone: 781 981-5624 From brideout at haystack.mit.edu Fri Jan 28 12:03:42 2005 From: brideout at haystack.mit.edu (William Rideout) Date: Mon Oct 23 17:53:08 2006 Subject: [OpenMadrigal-developers] Python Distutils In-Reply-To: References: Message-ID: <41FA706E.4070104@haystack.mit.edu> John Byrnes wrote: > Hello all, > > I wanted to suggest that the setupMadrigalWeb.py file be renamed to > setup.py and a separate README be included with the remotePythonAPI > distribution. This better facilitates the use of distutils for building > packages (RPM, wininstaller, etc.). IIRC, trying to build an RPM fails > when the setup script isn't named setup.py . John, Thanks, I didn't know that about the name of the setup.py file. I'll make those changes. > > Also, including a binary of the pnet library for Mac OSX on PPC with the > Matlab API would be nice. I can provide the file if you wish. I've stopped using pnet in my Matlab API because Matlab 6 and above has the urlread method built in. Are you using an older version of Matlab? Let me know if you find this Madrigal interface useful. Bill > > Regards, > John > -- > John Byrnes > Graduate Student > ECE Department > Boston University > byrnes@bu.edu > > _______________________________________________ > OpenMadrigal-developers mailing list > OpenMadrigal-developers@openmadrigal.org > http://www.openmadrigal.org/mailman/listinfo/openmadrigal-developers > > !DSPAM:41fa3c03172842067915901! > > -- Bill Rideout MIT Haystack Observatory Email: brideout@haystack.mit.edu Phone: 781 981-5624 From byrnes at bu.edu Sat Jan 29 03:04:50 2005 From: byrnes at bu.edu (John Byrnes) Date: Mon Oct 23 17:53:08 2006 Subject: [OpenMadrigal-developers] Python Distutils In-Reply-To: <41FA706E.4070104@haystack.mit.edu> References: <41FA706E.4070104@haystack.mit.edu> Message-ID: <032c397dcac99651f2640d7ac19ef914@bu.edu> In the python API distribution, I don't believe a README is required except to provide the user with build/install directions. The important thing is the setup.py change. > Thanks, I didn't know that about the name of the setup.py file. I'll > make those changes. >> Also, including a binary of the pnet library for Mac OSX on PPC with >> the Matlab API would be nice. I can provide the file if you wish. > > I've stopped using pnet in my Matlab API because Matlab 6 and above > has the urlread method built in. Are you using an older version of > Matlab? > Attempting to use the matlab API as documented on the OpenMadrigal website fails on at least the OSX version of MatlabR14 unless I compile the pnet.c file. I haven't looked too closely at your matlab code, but it appears that pnet is still needed. The matlab trace is at the end of this message. > Let me know if you find this Madrigal interface useful. I've just started playing with the interface, so it will take me some time to see if it can be used more effectively then the web interface. One option that I would find useful would be a flag to add a comment character (#,%,*) to the beginning of every header line. That would make the output files much easier to parse. Thanks!! John Matlab's output is listed below: >> url = 'transport.sri.com/madrigal' url = transport.sri.com/madrigal >> asdf = getMadrigalCgiUrl(url) ??? Attempt to execute SCRIPT pnet as a function. Error in ==> getUrl at 12 con=pnet('tcpconnect',host,port); Error in ==> getMadrigalCgiUrl at 17 pagedata = getUrl(url); From brideout at haystack.mit.edu Mon Jan 31 09:36:07 2005 From: brideout at haystack.mit.edu (William Rideout) Date: Mon Oct 23 17:53:08 2006 Subject: [OpenMadrigal-developers] Python Distutils In-Reply-To: <032c397dcac99651f2640d7ac19ef914@bu.edu> References: <41FA706E.4070104@haystack.mit.edu> <032c397dcac99651f2640d7ac19ef914@bu.edu> Message-ID: <41FE4257.7060603@haystack.mit.edu> John Byrnes wrote: >> > Attempting to use the matlab API as documented on the OpenMadrigal > website fails on at least the OSX version of MatlabR14 unless I compile > the pnet.c file. This is my fault. When I updated the API I only did the tar version, and not the zip version. I've updated both today, so please download a new version. There are a few new auxillary methods, but the basic code is the same. pnet should be totally eliminated from the distribution. Bill -- Bill Rideout MIT Haystack Observatory Email: brideout@haystack.mit.edu Phone: 781 981-5624