Ein Bielaczyc wrote: > I have a small customer looking to update their aged telemarketing > system. I ran across astGUIclient and Vicidial > (http://astguiclient.sourceforge.net/) during a Google search and was > wondering if anyone had any experiences to share, positive or > negative.
Well, you do have to realise that you're putting almost anyone who may have had a negative experience with ViciDIAL in the difficult position of effectively slandering it, or at least earning the ire and distaste of many other list members, most certainly including the authors. But, that's no reason for self-censorship. So, with apologies to Matt Florell and others: Personally, I've found that ViciDIAL generally works - in a practical, functional, utilitarian sort of sense in which programs work deterministically in accordance with their underlying instructions. I think if you want it to do what most people want it to do more or less out of the box, it's probably a good choice. The story is a bit different, however, in the unlikely event that you actually do care about what's under the hood. It proved to be impractical for my intended use because customisation was required, and the code is an absolute nightmare from a developer's perspective. It is a hodge-podge of naive, inefficient PHP and Perl written with absolutely zero regard for maintainability. It is impossible to read, has no discernable formatting characteristics, is often obfuscated, poorly spaced, arbitrarily indented, and follows no consistent or useful nomenclature or conventions. It's a lot of spaghetti code, and it does not leave one united with the impression that functional decomposition, abstraction or modularity is valued at all, let alone as a guiding value. I suspect many -- although certainly not all -- of limitations to its scalability stem from resource consumption caused by extremely inefficient algorithms, flow control constructs, and serial database interactions that involve repeatedly swapping data in and out of the programmatic layer in high-volume transactions, transforming it, and sending it back to the database. There also appears to be considerable reliance upon the database as a real-time IPC mechanism--another very deadly anti-pattern. Additionally, it has far too many processes, many of whose essence is not clearly or easily understood by the naked eye. If the code were readable, this wouldn't be so bad. But as it stands, in addition to the ugly hack that results from retrofitting astguiclient in this fashion, there are plethoric, innumerable Perl / AGI scripts whose coherence can only be depicted with evocations of a Rube Goldberg device. So, as long as you are interested only in the superficie, it seems to work pretty well, although I can't comment on the overall stability, bugs too much. However, if you are interested in development or customisation, you need to run for the hills, because nothing short of a complete, categorical, wholesale from-scratch rewrite -- one with some evidence of method -- is going to untangle the catastrophe that boils under the deck. -- Alex -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users