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

Asterisk asterisk at dotr.com
Tue Jan 11 17:52:19 MST 2005


Comments inline.

Peter Svensson wrote:
> On Tue, 11 Jan 2005, Asterisk wrote:
> 
> 
>>In my mind, (yes, a small one compared to the giants walking around 
>>here) There are several advantages in this method:
>>
>>a) Parsing one line of data per record is in order of magnitude easier 
>>to code.
> 
> 
> Not really, unless you have to invent string handling first. It is very 
> easy in C++/perl/java etc. It is not even hard in C with no libraries at 
> all.

I stand corrected for the languages you describe. I come from a database 
background, with a language that handles records much much better than 
the data currently presented.

> 
> 
>>b) As mentioned, further fields can be added at any time without 
>>breaking code
> 
> 
> The current format is tagged. How much easier can it get to add more 
> fields? At the moment the order is not fixed either which is nice from a 
> flexibility point. You can have optional fields that ar only output if 
> they make sense.

This was part of my problem - there was a varying number of lines per 
"record" which made my processing easier if it were one record per line. 
Again, that could be my blindness die to the language I use.

> 
> 
>>c) output can be exported directly into spreadsheets
> 
> 
> True, but a trivial amount of script magic can transform the current 
> tagged format into whatever you want. 

Why have all the various "listners" have to process the output, rather 
than have it presented ?

For more major post processing
> converting it to xml first may be useful/flexible.
> 

I really didn't want to go there - it would be the ideal solution however :)

> 
>>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.
> 
> 
> It is not fixed, I think thats is why you are thinking along these lines. 
> It is a tagged format. Given the nature of the data that is sent (what 
> fields are valid may vary) a tagged format is probably the only sane way 
> of representing the data.

If the data had a "start/end" tag, I would agree. However, it is 
difficult to find the end of the data because of the "optional" fields.

Thanks for the comments.

I may have to stick with the current format if I am the lone voice in 
the wilderness. I'm not that stupid to take on the rest of the * world ...

Julian.

> 
> Peter
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> 




More information about the asterisk-users mailing list