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

[Asterisk]

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
>