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 [EMAIL PROTECTED] Fax: +61 2 9345 4396 www.websitemanagers.com.au _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
