> > * It would be great if we could find another way to pass information > > about the intent instead of hard-coding in the functions as a string. > > I could make them constants and put them in the misc.py package. Reactions?
That's better, but I wonder if there's a cleaner way to do this. I can't think of one off the top of my head, but perhaps somebody else can/will. > > * Why is the protocol version included in the > > per-authority image configuration. Would you please explain why you > > chose to do it this way? > > Basically, I needed a place to store the protocol type and the > authority seemed the most logical since, at the moment, we don't have > mirrors and the setting is basically per-authority. What I was trying to ask was why is it necessary to store information about the server's protocol type. This is something that I would expect to remain constant. The server will get upgraded, and then you'll want to use the extended method. Could we just try the enhanced version and fall back to standard when servers don't support it? > > * Are we guaranteed to get a 501 error when sending this path? I would > > much rather we get something like a 404, and then fall back to the old > > protocol. This is going to cause confusion when we introduce content > > The old depot server will return a 501 -- guaranteed. I obviously > can't change what it returns :-) > > > mirrors, since they're actually not going to support catalog and > > manifest operations at all. In that case, it seems appropriate to > > return a 501, since the method isn't supported on the server side at > > all. Whereas in this case the method is implemented, but you can't > > find what was requested. > > The new depot server should return a 404 if you attempt a HEAD on a > manifest that doesn't exist. > > Can you clarify a bit? The rest of this discussion is effectively moot since old servers give us a 501 in this case. I'll find some other way to resolve any problems that come up with content mirroring. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
