On Tue, Dec 15, 2009 at 06:38:55PM -0600, Shawn Walker wrote: > [email protected] wrote: > >On Tue, Dec 15, 2009 at 04:43:07PM -0600, Shawn Walker wrote: > >>full updated webrev: > >>http://cr.opensolaris.org/~swalker/pkg-license-2/ > ... > > - lines 137-160: The transport should already create an opener for files > > that it has successfully downloaded using the MFile interface. This > > code should be simplified to check if the action's data attribute > > exists and is callable. If it is, then that's the opener this call > > should return. Otherwise, the license has already been installed > > and you can create a local opener. > > The only thing about that is that I have to wrap the opener again > with another opener since the data returned by that callable is gzip > compressed (I hope always).
If you don't want to re-wrap the opener, another possibility would be to actually invoke the install() method of the license actions after you download them. If they've been downloaded and installed, you're guaranteed to have a decompressed local copy available. If you decide to re-wrap the opener, please make the code be obvious about what you're doing. My current project is to perform parallel decompress/install. In order to do that, I have to make sure that the classes that I'm passing to the multiprocessing module can be picked, which means that lambdas and inline functions are out. One of the consequences is that I have to remove all of the inline def opener() functions from the actions code and create an actual class heirarchy of opener objects. > > I would avoid using the remote_opener under any circumstances, since > > it is not robust and can cause the client to fail from a variety of > > transport errors. > > Just as a point of reference, we were already using remote_opener > before with the info() api call. Yes, but it's used in a pretty obscure code path in info(). If you get a transport error there, it's not the end of the world. However, if you're trying to display a license that must be displayed and accepted before install can proceed, then having exceptions break that path is pretty disruptive. I would love it if info didn't use get_remote_opener, or even if it used it more safely, but since we're adding new code it seems better to use a transport method that's robust and handles the errors for the caller. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
