Shawn, How about if we consider the questions that we want to be able to answer using this data?
- How many people have installed package such and such? - How many people have updated package such and such to a new version? -- How many of those were a specific request to update that package? -- How many were part of an overall image-update? - How many people have looked at information about a package? To answer these questions, it really isn't necessary to send the command that triggered the operation, a transaction id. Also, if a client is installing hundreds of packages, then there will be hundreds of requests for manifests (with a little bit of information on each one). I'd like to suggest that we return to Stephen's original proposal of just sending the intent information: install/null install/[previous_version] info contents image-update/[previous_version] In the header of the manifest request. This allows us to answer the questions above. Tom Shawn Walker wrote: > Greetings, > > While looking into how to implement bug 2022 (client should provide > operational intent to server), one question that came up was just how > much information we could get away with sending in the header. > > Specifically, I've read multiple warnings posted on various pages that > say that the size of the HTTP header should be as small as possible for > various reasons. > > Right now, I'm thinking of sending the history start_state to the server > as that will tell us what the client is installing for the first time or > what they're upgrading from and upgrading to. I could also send along > the command that triggered it, the name of the operation (as perceived > by the client) and eventually a transaction id (that could be used to > help link error log entries to client tracebacks). > > For the cli, I'm not expecting the user to request more than one or two > packages (explicitly); however, for the gui, I could easily see hundreds > or thousands of packages being explicitly requested by the user at a > single time. > > With this in mind, this seems like quite a bit of information to pass > along in the header. As such, I've been considering a separate POST > operation before the client fetches a manifest (regardless of cache > status), begins a filelist operation, etc. that provides this > information instead of trying to squeeze it into the headers. > > Thoughts? > > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
