Bart Smaalders wrote: > Jordan Brown (Sun) wrote: >> Whatever you do, you want to ensure that it is compatible with >> download services like SDLC and its current Akamai back-end. > > Why? What needs to happen is that the design meets customer requirements > rather that be compatible w/ existing Sun infrastructure. If it works, > great - but that's not "whatever we do".
There are good economic reasons why Sun has centralized its download support, and why Sun has outsourced our downloads to Akamai. Sun cannot meet the customer's needs for downloadable software if it cannot do so economically. Our patch download infrastructure was originally a custom POST-based protocol, and those economic factors were the major reason that we reworked it to be compatible with SDLC and Akamai. Note, incidentally, that at least in theory customers get better performance from Akamai than they would from Sun directly, since Akamai serves the stuff from a worldwide network of servers. Another way to look at it is that if you design for a custom application with POST-based requests, it is difficult or impossible to change to alternative strategies like static servers or services like Akamai. If, on the other hand, you design for what appears to be a static service, you can service it from *either* a custom application *or* a more generic service. >> For patches and associated metadata, we have a server that accepts GET >> requests and may (or may not) redirect them to Akamai. I don't think >> you can do redirects on POST requests, which is an excellent reason to >> avoid them. > > We currently redirect from apache to our python daemon for post requests > @pkg.opensolaris.org. Hmm. Do you attempt to support generic web clients? I believe that if a standard web browser issues a POST and gets back a 3xx Redirect, it will follow up with a GET rather than another POST. This appears to be required by RFC 2616 section 10.3. >> Have you thought yet about entitlement? > > Of course... this is handled via client-side certificates; we'll need DB > lookups at runtime at the server end to handle multiple levels of > entitlements/repo. Well, unless you want to reinvent a number of wheels, you'll want to tie that into existing Sun download infrastructure, from whence it'll tie into the existing IBIS contract management infrastructure. There's some reason why client-side certificates are not optimal for the purpose. I never quite understood it, and don't remember all that I *did* understand, but I think it had to do with the difficulty involved in getting the identification information from the external SSL processors to the servers that were actually handling the request. One fairly mundane problem with client-side certificates is that you'll need a registration mechanism to tie them to the identities that the contract management stuff works with, currently Sun Online Account usernames and Sun Connection asset IDs. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
