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@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
_______________________________________________ Asterisk-Users mailing list Asterisk-Users@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
