Having thought about the more generic issue with 'leaky abstractions' a little more I would like to add the reverse of my scenario to the discussion.
all implementers of a flutch have a feature Y so we implement an option in our interface. Now the one of them (or a new kid on the block) solves the problem that this option is for in a totally different way. Their solution slowly becomes commonplace but only slowly and one of the big players, producer of implementation a, doesn't go for this solution. How do we migrate from generic option to a key/value pair that only the provider/element/guru for an a understands? regards, Daan On Sat, Oct 5, 2013 at 11:28 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > 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 >> >
