On Tue, 15 Jun 2004, Lombard, David N wrote:
Well, it appears OPD is not usable without a connection to the Internet. This is not apparent from the opd command line or GUI, e.g., the "Use these repositories EXCLUSIVELY" does not function in a useful manner as the main repository is *always* required.
The immediate problem, always trying to connect to the master OPD repository, appears to be worked-around by commenting out
read_repository_listing();
But, that requires an additional line to init both $package_filename and $repository_listing->{files}->{package_listing}. The actual solution in the attached patch was to add a "--nomaster" option to opd to allow for user-level control of Internet access and to initialize both variables unless they are already defined.
As the creator for OPD, I'm very ameniable to this solution.
I think my original intent was that this would be possible (be able to use OPD with either an alternate master or without a direct connection to OSCAR SF master), but it's quite possible that I hadn't thought through all the issues / coding logic to enable it to happen.
Feel free to commit the code for that.
Sidenote: now that OSCAR is installed into /opt/oscar, it is also possible to break opd up into multiple, smaller .pm files. I didn't do this before simply so that opd could be called without having to set an environment variable (or whatever) indicating where the OSCAR stuff was installed (e.g., OSCAR_HOME). Now that it's constant, this can be done easily, and might make the opd code more manageable.
Having done that, what about the opd GUI? This required an ugly hack to make the "exclusive" checkbox use the new "--nomaster" option. It's ugly 'cause the GUI is a little knotty, and the initial probe of the master ODP site must either time-out or be cancelled before the repositories can then be added and the "exclusive" checkbox checked.
I'm not familiar with the code logic of the GUI, but perhaps it would be possible to pre-load this checkbox by having the GUI do a quick ping of the master site -- or, better yet, ask OPD to do a "quick" ping (something that would potentially only take a few seconds to time out, not 30 or 60) to see if it can connect to the default master.
Or perhaps OPD should do this by itself, and therefore the logic of the GUI wouldn't need to change.
And perhaps it's also time to be a bit smarter about finding the default master for OPD. Perhaps it would be good to have back-end file-based defaults, so that OPD will [by default] use the same master that you used last time. And so on.
This might make the OPD experience a little nicer.
So, I can now query an arbitrary repository w/o Internet access, but alas, the "Download Selected Packages" button caused an immediate termination of the downloader.
This was due to an improper oscar_package.xml file; apparently OpderDownloadPackage.pm wasn't doing sufficient data checking and again the need to check the master OPD repository.
I guess we had always assumed correct XML. Do we need to provide support for non-correct XML?
Once I added support for the spiffy new "--nomaster" option and corrected my lousy XML, I noticed a silly typo in OpderDownloadPackage.pm, which is also fixed in the patch.
Excellent.
Finally, with the attached patch, the opd GUI is now able function without Internet access. It's a hack, but it works.
Sadly, none of this enables a proper file URI to work, e.g.,
file:///var/www/html/OPD/oscar_packages.xml
that is, I don't even get a listing of available files. Note, this URI correctly works in Mozilla or curl. I also tried (incorrect) prefixes like "file://" and "file:////" (the latter still works in Mozilla) -- they too failed in the downloader GUI.
I believe that this is due to the way that OPD tries to download things -- it uses perl's LWP or the wget executable, neither of which (I believe) support file:///.
So, the attached patch allows opd and the opd GUI to function in a more useful manner, where organizations can set up their own web-based servers without need for an Internet connection. The attached patch does *not* make the GUI more robust -- it still fails in the face of incorrect XML.
I'd say to go ahead and commit the opd patch. Can't comment on the GUI patch.
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
