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

[Adam Goryachev]

On Wed, 2005-01-12 at 00:47 +0000, Asterisk wrote:
> Comments inline...
> 
> 
> Christopher L. Wade wrote:
> > Comments inline...
> > 
> > Asterisk wrote:
> > 
> >> However, I feel that it would be more useful for the manager output to 
> >> be tab delimited, one record per line:
> > Why?  How?
> 
> Because I come from a database background - I'm used to accessing 
> records, and fields within those records.

We currently output records, they are just delimited slightly
differently.

field separator = \n
record separator = \n\n

So, you need some sort of 'class' which will simply grab the next
record, and then translate the record into whatever format you need.

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

You really need some sort of 'class' so you can just grab the next
record, and then check the status of 'Agent' or whatever data element
you want.

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

No, you have the wrong terminology. Even in your suggestion, you need to
read one *record*. Either method, you still need to read a record before
you can decide what to do with it. In your suggestion, one record
happens to be one line.

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

IMHO, it is 'harder' to parse the current format, but it is easier to
maintain compatibility with previous, current, and future requirements.

It is harder, until you actually go and write a couple of functions to
read/parse the records. Consider this as like using odbc instead of
mysql directly...

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

You should be able to find a library for pretty much any language which
can do the read/parse for you. Having said that, I am about to look for
one for some other project I'm embarking on.

The only other method I would consider is XML, but I personally feel
that XML would *add* to the complexity... Although again, there probably
is an XML parser library available for any language, I would think that
the xml library would be much more complex than dealing with the current
output.

Just my 0.02c worth
-- 
 -- 
Adam Goryachev
Website Managers
Ph:  +61 2 8304 0000                        adam at websitemanagers.com.au
Fax: +61 2 9345 4396                        www.websitemanagers.com.au