Watkins, Bradley wrote: > *From:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] *On Behalf Of *Wolfgang > Pichler > *Sent:* Wednesday, September 05, 2007 8:00 AM > *To:* [email protected] > *Subject:* [asterisk-dev] app_queue membercount > > Hi all, > > with r76801 the application queue was patched to now include a > variable membercount to keep track of the number of queue members. > > As Michelson noted in the changelog - as a side effect the > QUEUE_MEMBER_COUNT function did also changed to return the number > of members regardless of their state. > > I think that may people still want to use the old method, to get > the real member count (members which are logged on). (we are one > of those peoples....) > > In my opinion there are 3 values which are from interest > - the complete member count (as it gets now returned by > QUEUE_MEMBER_COUNT) > - the logged in member count (as QUEUE_MEMBER_COUNT did it > before the change) > - the free member count (how many logged in members do not > have a call) > There are two possible ways to implement this > - Create an own function for each value of interest > (QUEUE_MEMBER_COUNT, QUEUE_AVAILABLE_MEMBERS, QUEUE_FREE_MEMBERS) > - Add a parameter to the QUEUE_MEMBER_COUNT function to > control which value it should return (no parameter = current > behaviour, parameter l = old behaviour, parameter f = only free > members) > > > > Personally, I think the last one is the closest. However, I would > rather see it implemented as a function QUEUE_MEMBER which will take > parameters COUNT, AVAILABLE, and FREE (like how CALLERID takes NUM, > NAME, etc.). > > Just my .02c > > Regards, > - Brad > ------------------------------------------------------------------------ > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev BJ Weschke made mention of possibly adding such a dialplan function for 1.6 and I think it's a really good idea. The only difference between your idea and the way I think it should be done is that since all the data that those functions are reporting are pertinent to a specific queue, they should be handled by functions like QUEUE(MEMBER_COUNT), QUEUE(AVAILABLE), QUEUE(FREE).
A QUEUE_MEMBER (or possibly even just MEMBER) function is a good idea too, but it would be better for retrieving information about a specific member, like paused status, penalty, number of calls taken, etc. setinterfacevar already provides this information but having it available with a more uniform syntax would be a plus. Mark Michelson _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
