H Chiradeep, I am hesitating to keep on about my case of httpClose as this is about the more general subject you gave this thread, so please take my referals to it as examples.
so it is in a sense keepAlive (formerly known as ! httpClose) we are talking about. Then there is a matter of how to implement it as I understand you have objections to the part where it is in the networkoffering. Let's take that back to the review thread, alright? Remains the question of the new feature X that will be common good in next generations. How art we dealing with that? And in this case maybe X is default for most but !X is default for implementation c. To that I'd say implement the options as and take the default from the largest group of implementations. In httpClose you could think of default is to keepAlive. I didn't do this to remain backwards compatible. If that is not a problem I think the engineers at Schuberg Philis can live with a change of hardcoded settings. I don't like that, hence my implementation. regards, Daan On Sat, Oct 5, 2013 at 12:56 AM, Chiradeep Vittal < chiradeep.vit...@citrix.com> wrote: > I've checked the Netscaler and HAProxy docs, this appears to be artifact > of the HAProxy implementation (inability to support keep-alive). > For a cloud operator that chooses Netscaler or F5 for load balancing, this > won't make any sense. > > On 10/3/13 12:55 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: > > >On Thu, Oct 3, 2013 at 9:02 PM, Chip Childers > ><chip.child...@sungard.com>wrote: > > > >> a model for extensions like that makes perfect sense. > > > > > > > >This model sound fine indeed. It makes no sense for httpClose however. > > > >Here's my concern: > >So when an early adapter is implemented and the rest of the market comes > >to > >their senses, how do we migrate without running into migration/upgrade > >problems? > >httpClose is a flag controlling connection pooling. I probably choose the > >wrong name. It is something that any implementation will support or should > >have supported already. Am I going to implement it as a key/value now to > >later implemented as I have done anyway? I don't like this idea. > > > >Don't get me wrong the pattern described by you guys is fine in some > >situations. I don't think it is applicable to this feature. > > > >regards, > >Daan > >
