[asterisk-dev] app_queue membercount

[Atis]

On 9/5/07, Mark Michelson <mmichelson at digium.com> wrote:
> Atis wrote:
> > On 9/5/07, Watkins, Bradley <Bradley.Watkins at compuware.com> wrote:
> >
> >> 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)
> >>
> >
> > Seems good. However i don't understand meaning of parameter I.
> >
> >
> >> 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.).
> >>
> >
> > This might be even better, but how to preserve compatibility?
> > Shouldn't QUEUE_MEMBER_COUNT then act in old behavior, but
> > QUEUE_MEMBER return result requested.
> >
> > Regards,
> > Atis
> >
> >
>
> If QUEUE and QUEUE_MEMBER functions were introduced, what we would do is
> deprecate QUEUE_MEMBER_COUNT (as well as other queue-related values), so
> that in version 1.6, the user would get a warning that they are using a
> deprecated function, and in the following version, the
> QUEUE_MEMBER_COUNT function will no longer work. This is the same
> procedure used whenever something is deprecated.

I completely understand that, however i was referring to changes
mentioned in first mail (i'm not sure what version is r76801 - is it
already released, or just in trunk), meaning - if QUEUE_MEMBER_COUNT
is going to be deprecated, shouldn't it preserve old behavior -
duplicate QUEUE(AVAILABLE). There might be some people that upgrade
without reading changelog.

Regards,
Atis

-- 
Atis Lezdins,
IT Responsible of BEST Riga,
atis at BEST.eu.org
ICQ: 142239285
Skype: atis.lezdins
Cell Phone: +371 28806004 [Tele2, Latvia]
Work phone: +1 800 7502835 [Toll free, USA]
?BEST? -> www.BEST.eu.org