On Nov 20, 2007 8:13 AM, Webb, Adam
Greetings,
I do think an ifeffit-dev list and/or wiki area is a fine idea. I don't know how many others would be interested in this, but it might allow for more open development, and keep the ifeffit mailing list more for usage questions. Any other opinions on this?
I second the idea. A -dev list would also help avoid confusion. I can see that people might get really confused if one set of people are talking about some software in development and other people are talking about the program that people are using.
Agreed. I will set up a devel list (it may be a couple weeks). The docs for development should also be improved.
For example, a plugin like structure might be used. Someone adding a new function could for example write a plugin to do something like: 1. ask ifeffit for data and other needed information 2. do some tranform/filter/magic on data 3. return data to ifeffit Other people could use plugin by calling it from within ifeffit. You can do this now with the wrappers but it appears to me that this might be easier to do with tdl and/or demeter as these things seem better designed to do just that. Perhaps Matt or Bruce would like to comment further.
As Bruce said, with the simple interfaces to Ifeffit from C/perl/python/tcl, one can do the steps you outline, though they are perhaps at a lower level than would be desirable. One important missing item is that these interfaces only go to the base library, and cannot connect to other libraries built on top of it. While a python script can call ifeffit, it cannot call Demeter or Hephaestus. If the idea is to use the ifeffit library for core XAFS functionality, this is not a terrible approach, but it does have serious drawbacks if the goal is a more comprehensive and extensible set of tools. I think the problem is challenging but solvable. With TDL, it will be much easier to add functionality "to the core" -- as any python module can be exposed to TDL. But that doesn't solve all the problems, specifically the cases where one would want to use procedures coded in a language such as Perl or Java or Mathematica (ie, anything other than C, Fortran, or Python), which Python cannot readily use. And that, I think, may be a part of what both you and Mauro are struggling with. You'd like to use some "core functionality", but hopefully wrapped up at a higher level as Demeter is, and perhaps some other libraries (DFT, processing reflectivity data, etc) that may be implemented in a different language. At some point, we're going to have to figure out how to avoid these language conflicts. Again there are ways to solve them, but we haven't gotten there yet. I've struggled with this too. I have some of Hephaestus' capabilities in Python, but by no means all of them. I've been reluctant to re-code it all in Python, but at some point I might break down and do this. Personally, I'd love to have a web-based Hephaestus, with a documented API, so that I could get the data. --Matt