On Wed, May 21, 2003 at 10:36:56PM -0500, Joe Cooper wrote: > Michael Stenner wrote: > > I haven't been following the failover thing at all. So with failover, > there can be multiple baseurl entries per serverid? almost exactly. The probable syntax will be a whitespace-separated list of uris in a single baseurl entry. But that detail isn't relevant here. > > If we deal with this by having options in the config file, you're > > sorta screwed. If the info is buried in the url, then you can do it > > PER url. I can think of three real options, in order of increasing > > technical pain and complexity. > > > > 1) allow options only - build up the url where needed (ftp, etc) > > This is where I've been going, obviously, because Seth pointed me in > that direction, and I had no strong objections to it. (BTW-Seth, was > there a reason to switch to urllib2, instead of urllib, other than just > that it is newer? It seems unnecessarily complicated and new-fangled > for what yum has to do, while urllib is dead simple. But I'm a Python > newbie, so I'm not allowed to hold strong opinions.) The reason is keepalive. It is a massively useful feature for a lot of people. urllib2 is better than urllib in almost every way. Something only seems unnecessarily complicated until you need to do something new. Then the unnecessarily complicated thing seems powerful, and the dead simple thing seems limiting :) > > 2) allow url-embedding only - for the new http stuff, that would > > require pulling them out of the url and dealing with them > > correctly. > > This wouldn't be that hard. The complexity that results is made up for > by the simpler FTP case (in the FTP case, with user and password > directives, we have to build up the embedded URL). It also has the > minor benefit of keeping the same syntax that currently works in earlier > urllib-based yum versions. I lean towards this being the Right Way for > that reason. I tend to agree. > > 3) allow both - url-embedded info overriding option info. This way, > > if you have all the same auth info, just use the options. If > > they're different, then encode them in the urls. This is the best > > of both world for users, and worst of both worlds for the coders. > > I'd really rather not see two ways to deal with auth info. It is > inconsistent for the user, harder to program, and provides no benefits > to the user that I can think of. I hold a strong opinion on this one, > just from a user perspective. Pick one way, and use it universally for > all types of server auth info. The provided benefit is this: If I put six servers in a failover list, and they all require the same username and password, then with option 2, I must put that username and pass in all six uris. That's bulky and I need to change things in six places when the password changes. Allowing both syntaxes would let me just set it once via the options. Still I tend to favor option 2. I'm just pointing out that there is some tangible benefit. > I'll also mention that from perspective of developers of GUIs, multiple > syntaxes for the same thing make life more difficult than necessary and > bugs in the GUI/docs/etc. more likely. I say this from the perspective > of one planning to add yum support to Webmin's Software Packages module > in the next week or two. Agreed. > > On Tue, May 20, 2003 at 12:49:46AM -0500, Joe Cooper wrote: > > Joe, I've done this... sorta. I've derived from > > urllib2.HTTPPasswordMgr and overridden find_user_password so that > > there is a "default" realm. Anything added with realm=None will get > > put there. > > Yeah, I was talking to someone via IRC the other day (thanks Tres!) > about this, and he seemed to think the HTTPPasswordMgrWithDefaultRealm > would do what I want without even having to override anything. I > couldn't figure out how to make this one go when I was working on it > over the weekend, but I can only safely plead ignorance rather than > claim the documentation is lacking significantly, though that would be > my first instinct were it a language I know better. Hah. I hadn't noticed that. Basically, they did it in EXACTLY the same way I did. Makes me feel smart and stupid at the same time :) I'll switch that over :) > > The biggest change that I've made is that you do not need to rebuild > > the handler every time you get a file. It is sufficient simply to add > > the username/password/realm to the existing handler. With that > > change, the part that happens inside urlgrab is reduced to: > > > > if username and password and http_auth_handler and scheme == 'http': > > http_auth_handler.add_password(realm, host, user, password) > > This makes sense. I noticed that quite a lot of stuff was persistent > between calls to retrygrab, once I was finished with the bulk of the > work. I don't understand why they are persistent yet, but now that I > see that they are this kind of approach makes more sense. Basically, it's persistent because it can be. It's nice to not have to re-initialize a lot of code that basically does the same thing. One advantage that we're not really using there is that you could "preload" the usernames/passwords at program startup and then not pass them in on each call. The password manager stores them anyway. The reason we're not doing this is so that we can keep urlgrab and retrygrab acting like independant events. > > I'd still be interested in your ftp code. I'm holding off on working > > on that until I get some replies to my question. If you're interested > > in seeing the actual code, I'll send it to you. Otherwise, I'm going > > to wait to see which way folks want to go before committing. > > Go ahead and send over what you've got and I'll add FTP support > tomorrow. It sounds like your changes make things a little cleaner than > my implementation, and I'll be happy to be rid of the weird reliance on > the keepalive stuff never changing. OK. Give me a chance to put in the default realm stuff and I'll pass it along. > I'll also do some more experimentation with the > HTTPPasswordMgrWithDefaultRealm class to see if I can make it go. I don't think you need to, but you can. I suggest you work based on the version I send you (which will already have it). That should save us both a lot of work. -Michael -- Michael Stenner Office Phone: 919-660-2513 Duke University, Dept. of Physics mstenner@xxxxxxxxxxxx Box 90305, Durham N.C. 27708-0305
