[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