Comments inline...
Christopher L. Wade wrote:
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 :)
Yup - it's working with the current record structure. I've figured out that the code would be half the size if dealing with a tab-delimited one record per line structure, hence my discussion.
However, I feel that it would be more useful for the manager output to be tab delimited, one record per line:
<snip>
Why? How?
Because I come from a database background - I'm used to accessing records, and fields within those records.
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 :)
Too kind :)
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.
True, that's why I find it easier because of the reason above.
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.
Whoo hoo. At least I score one point :(
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.
My problem with this is that you have to keep reading the stream until you know that you've got all the information you need, rather than reading a single line and knowing you've got the info.
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.
Not at all - quite the opposite. As long as the version number increases, (* only spits out the latest version of the record layout) then everything is backwardly compatible - all you are doing is adding extra fields to the end of the record. Thus, any "old" code only expects a number of fields less than is being provided.
Both of these involve
more work than the current model - for the programmer and for the running * process.
As mentioned above, I reckon that I could half the complexity of my current code if the data were presented this way.
As for *, it just dumps the latest version. No worries about prior versions because legacy code will still read the data correctly.
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
_______________________________________________ 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
