On Wed, 2005-05-04 at 19:52 +0200, Olle E. Johansson wrote: > NicolÃs GudiÃo wrote: > >>> Event: Hold > >>> Holdstatus: On | Off > >>> > >>> Event: ParkedCall > >>> PCstatus: Parked | Unparked | GivingUp > >> > >> Why not just "Status" or "State"? There's not really any particular > >> reason why each event needs its own state header name, is there? > > > > > > I totally agree... > > > Do you agree that we should use the same header field name to indicate > many different things, like the way we use "Channel:" for just about > anything right now?
Yes. We already have the Event that gave us the proper meaning/context for the headers below. BTW, we use Channel now to specify a Channel, or I'm missing something? A few days ago Kevin commited a patch I made with some new manager events related to Zap channels and DND state (bug 4070). I used the header names that were already available on ZapShowChannels, ZapDNDOn and ZapDNDOff. Kevin did some modifications to my patch to make it more general, changing the ZapChannel header to Channel, etc. I fully agree with those changes, but we might extend those changes to the Zap manager comands also, although that will break backwards compatibility. ZapDNDOn and ZapDNDOff takes the 'ZapChannel' header to do its magic. And the ZapChannel must be the channel number only. IMHO, we must change that header to be 'Channel' and its value 'Zap/XX'. Then, in ZapShowChannels we also need to change the Channel header to return 'Zap/XX' instead of 'XX' In the DND state for Zap channels I used "Status" as the header and 'enabled/disabled' as values, we must define the name for the state/status header for other events (State or Status?) and the possible values as for Hold: 'on|off' or 'enabled|disabled'? Maybe we can use 'State' for channel states as 'Ring', 'Ringing' and 'Status' for other kind of events, like Hold, DND, etc.. Is it best to have unique headers for those events? Is it simpler for developing manager applications? I think that the answer is no.. but thats my opinion. A header by itself is not enough to know the state of anything, you have to relate it to the Channel, Uniqueid and/or the Event. If we use different headers, we still need to relate them to the Channel or Uniqueid for that event block. -- Nicolas Gudino <[EMAIL PROTECTED]> _______________________________________________ Asterisk-Dev mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
