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: [EMAIL PROTECTED] 7089 Ryburn Drive Phone: (901) 872 2272 / (800) 840 8400 Millington, TN 38053 Fax: (901) 872 8482 USA
_______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
