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

[Peter Svensson]

On Wed, 12 Jan 2005, Asterisk wrote:

> Peter Svensson wrote:
> > On Tue, 11 Jan 2005, Asterisk wrote:
> > 
> >>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.

You just view a single LF as the field separator and a double LF as the 
record separator. In other workds, instead of assembling the record until 
the string "\n" is found you assemble until "\n\n" is found.

> >>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 ?

Because it is _much_ simpler to parse and update a tagged format than a 
tab separated one? Remember, the events and command responses are _not_ 
lines from a database with exactly the same fields each time. Think of 
them as overloaded RPC perhaps.

> > 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.

Not at all hard. If you insist on using line buffered reads then you read 
until you find an empty line. If not, you just read until the token "\n\n" 
is found.

Peter