Kevin, [...] > I rather like the idea of introducing this feature without changes to the > existing API. I'd like to see us continue in the current direction. By > forcing changes upstream, we make it harder to adopt this enhancement.
yes, I would definitly second that ... the easier we make it for existing projects to adopt the new functionality the better. (look how google made their chrome browser sucht that it installs on an unpriviledged windows user account just like that ... very clever) I think the key here is to document what happens, so if the library opens a connection and pools it, this should be explained in the docs. [...] > I see your point. There are problems with the throttling approach on > either extreme. Not sure how this is applicable here, but an idea I have been toying with recently is that the application could throttle itself based on how long it takes to send a block of data to the target without throttling and then starts backing of from this a little. So whenever the system is not able to keep up, the sender will automatically throttle itself a little more. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch [EMAIL PROTECTED] ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
