I honestly don't know enough about this problem to give you a more sensible answer. Adding a second HTTP operation into the mix is asking for performance problems. I wandered the halls before sending out this e-mail. As far as I can tell, only Stephen knows what Stephen wants for client intent. We should make him write this down, and then go from there.
My understanding from previous discussions was that we wanted/needed something lightweight and easily attached to the HTTP request. IIRC, we had discussed using HTTP headers, modifying the URL, and other related trickery. I'm not trying to unilaterally shoot down your proposal, but it seems like it might be worth considering alternate approaches, or keeping header information to just the bare minimum. Without understanding the requirements for this feature, it's hard for me to provide you with more insightful advice -- sorry :(. -j On Wed, Sep 17, 2008 at 05:58:46PM -0500, Shawn Walker wrote: > [EMAIL PROTECTED] wrote: > >> 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. > > > > This doesn't seem like a good idea. We're adding a second round-trip > > and connection setup / tear-down into the process of starting an > > operation. This is going to make these harder to streamline in the > > It's not my preference to do this, certainly. But isn't there a size > limit? How do I guarantee I'm not sending along a megabyte of text in > the header? I'm concerned that this will cause problems. > > > future. How do you envision this working once we start sending our FILE > > requests via pipelined http GETs? > > That was the other reason I asked... > > I'm concerned about header size. > > -- > Shawn Walker > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
