On Sunday 21 December 2008 15:14:18 Philipp Kempgen wrote: > Tilghman Lesher schrieb: > > On Sunday 21 December 2008 13:07:05 Philipp Kempgen wrote: > >> Tilghman Lesher schrieb: > >> > The Disconnect command only frees the resources associated with the > >> > connection. The Clear command is needed to destroy resources > >> > associated with any outstanding query. Of course, if you get a hangup > >> > prior to completing either of these cleanup commands (and you aren't > >> > explicitly handling those in the "h" extension), you'll get a resource > >> > leak. > >> > >> That's why the MySQL functions should either be fixed or removed. > >> They make it too easy to shoot yourself in the foot. > > > > They do, but they also allow something that I currently do not permit in > > func_odbc: retrieval and destruction of results and handles by a channel > > other than the one which created them. So you could plausibly use the > > MYSQL command for something like a serialization operation, whereby > > each channel fetches a row in turn and uses the values therein for a > > coordination procedure of some kind. I'm not quite sure what the value > > of that is, but it is possible with the current model. > > > > Like every other powerful utility, you may choose to use the rope to make > > a bridge or a noose. > > So if that's a good thing because it is powerful that raises the > question why you don't allow it in func_odbc then.
Because while func_odbc is admittedly an overengineered solution to a problem I once had to solve, I did not have a need for such functionality. If someone had a use case for why that would be a useful feature within func_odbc, I would probably find a way to do it. > I guess nobody needs it. I wouldn't go that far. In fact, there's probably very few people who share it amongst multiple channels. However, if I make the assumption that people will have no need for a particular feature, I usually find out that I'm wrong about six months too late. And then I get to spend time figuring out how to meld two different feature sets together, despite having removed one to make the other more easily written. So my reticence on removal is based upon past experience. -- Tilghman _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
