[Asterisk-Users] Changes to manager outputs - A discussion

[Christopher L. Wade]

Comments inline...

Asterisk wrote:
> I am currently writing a prototype agent monitoring system, which (as 
> most others in question) simply monitors the output from the event 
> system, and displays the relevant information. I would hope to donate 
> this back to the community once it works properly :)
> 

Great :)

> However, I feel that it would be more useful for the manager output to 
> be tab delimited, one record per line:
<snip>

Why?  How?

> 
> In my mind, (yes, a small one compared to the giants walking around 
> here) There are several advantages in this method:
> 

Don't belittle yourself, everyone's brain starts out as ONE cell...
But grows exponentially :)

> a) Parsing one line of data per record is in order of magnitude easier 
> to code.
> 

This is language and implementation specific.  I can parse a million 
line file or a one line file with the same piece of code, just depends 
on how you choose to do it.

> b) As mentioned, further fields can be added at any time without 
> breaking code
> 

Same with the current format, even more so that your tab delimited idea.

> c) output can be exported directly into spreadsheets
> 

Ok, on this one you win.

> d) It is very easy to skip records that you are not interested in - If 
> field 2 is not "Agents" then ignore
> 

Again, implementation specific.  For instance, you've got to read the 
whole pipe to clear way for the next message regardless of your method 
or the current, and with my statement for your point 'a', again - no 
real gain.

> In order not to break existing code, we could provide a flag or setting 
> to determine which output format to use: further more we could slowly 
> update all of the manager events until they are all available in old and 
> new formats.
> 

This already exists.  Need a new key/value pair in the event, just go 
add it.  You won't break anyone else's parser unless they did exactly 
what you say in the next paragraph and assume the messages are fixed in 
all respects - which they aren't.

> I know that perhaps I've talked a load of BS - I would appreciate it if 
> people could comment on this before I head up a blind alley. I feel that 
> it would be more useful and easier for us as developers if there were a 
> common event manager layout, rather than a fixed number of lines per 
> action type / event type, and one that follows a more common data / 
> record layout.
> 

etc...  Again, your format is even more 'fixed'.  With your layout you 
have to specify the version you want * to give you, otherwise * has to 
spit out all versions to retain compatibility.  Both of these involve 
more work than the current model - for the programmer and for the 
running * process.

> Please feel free to comment / flame whatever.
> 
> exten => 999,n,GetFlameSuit(MaxStrength)
> exten => 999,n,WearFlameSuit(MaxStrength)
> exten => 999,n,HoldBreathAndWaitToBeFlamedBigTime()

Dial(flaming/999)

-Chris

-- 
Christopher L. Wade                     Unistar-Sparco Computers, Inc.
Senior Systems Administrator                            dba Sparco.com
Email: clwade at sparco.com                             7089 Ryburn Drive
Phone: (901) 872 2272 / (800) 840 8400            Millington, TN 38053
Fax:   (901) 872 8482                                              USA