Thursday, September 13, 2007

VoIP SIP SDK for .NET and Win32 COM 1.0

VoIP SIP SDK - A powerful and highly versatile VoIP SDK to accelerate development of SIP applications. Our brand-new SIP SDK provides a powerful and highly versatile solution to add quickly SIP (Session Initiation Protocol) based dial and receive phone calls features in your software applications. It accelerates the development of SIP/ RTP compliant soft phone with a fully-customizable user interface and brand name. The conaito VoIP SIP SDK contains a high performance VoIP conferencing client capable of delivering crystal clear sound even for both low and high-bandwidth users and SIP compatible devices (hardware and software). It enables a worldwide communication over the internet or intern networks either by speaking and/or by text messages and delivers superior voice quality by integrating advanced configurable digital voice processing features including auto gain controller, acoustic echo cancellation, noise cancellation, reverb cancellation and Voice activity detection. Here is a list of the main features of the conaito VoIP SIP client: * Easily make and receive SIP (Session Initiation Protocol) based phone calls through any SIP gateway or SIP compliant IP-Telephony service provider * VoIP conferencing with crystal clear sound even for both low and high-bandwidth users (G711 A-Law, G711 U-Law and iLBC Codec). * Registration on SIP Server (SIP Registrar). * Instant text messaging. * Microphone and Speaker Visualization support. * Microphone and Speaker Volume with Mute support. * Audio device selection. * Fully-customizable user interface. * Packetloss resistant (by using iLBC codec). * Supports OLE Automation (scripting) by providing IDispatch interface and custom interfaces for C/C++ developers. * Works with all kind of Internet connections. * Royalty free licensing * No Yearly/Monthly fee * Very easy to incorporate * VAD (Voice activity detection), Reverb, Echo and Noise cancellation or suppression, AGC (auto gain controller).

Building Hybrid Systems with Boost.Python

Python and C++ are in many ways as different as two languages could be: while C++ is usually compiled to machine-code, Python is interpreted. Python's dynamic type system is often cited as the foundation of its flexibility, while in C++ static typing is the cornerstone of its efficiency. C++ has an intricate and difficult compile-time meta-language, while in Python, practically everything happens at runtime.

Yet for many programmers, these very differences mean that Python and C++ complement one another perfectly. Performance bottlenecks in Python programs can be rewritten in C++ for maximal speed, and authors of powerful C++ libraries choose Python as a middleware language for its flexible system integration capabilities. Furthermore, the surface differences mask some strong similarities:

'C'-family control structures (if, while, for...)
Support for object-orientation, functional programming, and generic programming (these are both multi-paradigm programming languages.)
Comprehensive operator overloading facilities, recognizing the importance of syntactic variability for readability and expressivity.
High-level concepts such as collections and iterators.
High-level encapsulation facilities (C++: namespaces, Python: modules) to support the design of re-usable libraries.
Exception-handling for effective management of error conditions.
C++ idioms in common use, such as handle/body classes and reference-counted smart pointers mirror Python reference semantics.
Given Python's rich 'C' interoperability API, it should in principle be possible to expose C++ type and function interfaces to Python with an analogous interface to their C++ counterparts. However, the facilities provided by Python alone for integration with C++ are relatively meager. Compared to C++ and Python, 'C' has only very rudimentary abstraction facilities, and support for exception-handling is completely missing. 'C' extension module writers are required to manually manage Python reference counts, which is both annoyingly tedious and extremely error-prone. Traditional extension modules also tend to contain a great deal of boilerplate code repetition which makes them difficult to maintain, especially when wrapping an evolving API.

These limitations have lead to the development of a variety of wrapping systems. SWIG is probably the most popular package for the integration of C/C++ and Python. A more recent development is SIP, which was specifically designed for interfacing Python with the Qt graphical user interface library. Both SWIG and SIP introduce their own specialized languages for customizing inter-language bindings. This has certain advantages, but having to deal with three different languages (Python, C/C++ and the interface language) also introduces practical and mental difficulties. The CXX package demonstrates an interesting alternative. It shows that at least some parts of Python's 'C' API can be wrapped and presented through a much more user-friendly C++ interface. However, unlike SWIG and SIP, CXX does not include support for wrapping C++ classes as new Python types.

The features and goals of Boost.Python overlap significantly with many of these other systems. That said, Boost.Python attempts to maximize convenience and flexibility without introducing a separate wrapping language. Instead, it presents the user with a high-level C++ interface for wrapping C++ classes and functions, managing much of the complexity behind-the-scenes with static metaprogramming. Boost.Python also goes beyond the scope of earlier systems by providing:

Support for C++ virtual functions that can be overridden in Python.
Comprehensive lifetime management facilities for low-level C++ pointers and references.
Support for organizing extensions as Python packages, with a central registry for inter-language type conversions.
A safe and convenient mechanism for tying into Python's powerful serialization engine (pickle).
Coherence with the rules for handling C++ lvalues and rvalues that can only come from a deep understanding of both the Python and C++ type systems.
The key insight that sparked the development of Boost.Python is that much of the boilerplate code in traditional extension modules could be eliminated using C++ compile-time introspection. Each argument of a wrapped C++ function must be extracted from a Python object using a procedure that depends on the argument type. Similarly the function's return type determines how the return value will be converted from C++ to Python. Of course argument and return types are part of each function's type, and this is exactly the source from which Boost.Python deduces most of the information required.

This approach leads to user guided wrapping: as much information is extracted directly from the source code to be wrapped as is possible within the framework of pure C++, and some additional information is supplied explicitly by the user. Mostly the guidance is mechanical and little real intervention is required. Because the interface specification is written in the same full-featured language as the code being exposed, the user has unprecedented power available when she does need to take control.

Saturday, May 26, 2007

What can the VoipCenter SIP App Server be used to deliver?

CCXML has been used by Voxeo's customers to create any call control application imaginable, including: Back to Back SIP User Agents (B2BUA), SIP redirect servers, SIP load balancers, Virtual or "hosted" IP-PBX and call-center / ACD solutions, click-to-dial SIP call launchers, follow-me-find me applications, and more.

When combined with our VoipCenter SIP Mediaserver, our customers have also used CCXML to deliver speech driven conferencing, call recording platforms, emegency notification / audio broadcast services, auto-attendant applications, telephone surveys, unified messaging platforms, bill payment solutions, voice broadcasting services, emergency notification services, and general speech or touch-tone driven IVR.

What is CCXML?

CCXML is the call control application standard from the World Wide Web Consortium (W3C), the same standards body that delivered HTTP and HTML -- arguably the two most successful applicaton development standards ever created. CCXML gives VOIP developers total control over how phone calls are placed, answered, transfered, conferenced, routed, and more. CCXML works hand-in-hand with any web application server or platform to enable dynamic, intelligent control over all VOIP calls.

VoipCenter SIP Application Server Software

The VoipCenter SIP Application Server software is built on Voxeos proven Call Control XML (CCXML) engine and has routed over one billion calls since its first production deployment in early 2002. CCXML lets any company create intelligent, dynamic SIP applications that can screen, route, transfer, and initiate SIP VOIP calls - including SIP redirect, proxy, and Back-to-Back User Agent (B2BUA) applications. The VoipCenter SIP Application Server also supports least-cost and multi-network call routing with the ENUM route directory standard.

Performance Evaluation of an XML-Based Conference Control Protocol for Centralized VoIP Conference

For communication between heterogeneous conference systems, it is important to build a conference control protocol independent from signaling protocols. We simulate an XML-based conference control that is under consideration as a standard mechanism. We describe the framework and operations for easy implementation in heterogeneous conference systems. The simulation results show that the proposed control protocol provides a consistent service for an increasing number of conferences and participants in small to mid-size centralized conferencing

Microsoft partners with VoIP suppliers

15 phone suppliers support Microsoft software
Nancy Gohring

Microsoft is launching a qualification programme for phones that are compatible with its unified communications products.

On Monday, Microsoft will show off 15 phones made by a variety of vendors including Samsung, LG-Nortel, NEC, Plantronics, Asus, GN, Polycon, Tatung and Vitelix that will carry a sticker alerting customers that they are certified for use with Microsoft Office Communications Server 2007 and Microsoft Office Communicator 2007.

The Microsoft communications software is available to users that are part of a public beta programme. Combined with other Microsoft programmes, they unify email, instant messaging and video conferencing functions so that users can do things like click on an email message to make a VoIP (voice over IP) call to its sender. The software also supports standard desk phone features.

Microsoft designed the software to be compatible with phones already on the market. The new qualification programme is meant to assure buyers that devices will work out of the box with Microsoft's unified communications products.

In order to qualify for the certification, handsets must include wideband audio support, comply with a wide range of VoIP codecs and include specific user interface elements, said Eric Swift, senior director of unified communications product management for Microsoft.

Some of the new phones connect directly to a USB (Universal Serial Bus) port so that mobile workers can bring the phone with them and use it along with their laptop to access features typically only support on desk phones, like call forwarding and conferencing.

Other new phones include Bluetooth and video capabilities.

"We're looking to ignite partner innovation to bring software economics to what has been proprietary," said Swift. Microsoft hopes that the communications software and the qualification program will make it easier for hardware developers to create innovative new phone products in a phone industry that he describes as remaining stagnant for many years.

Microsoft's Office Communications Server competes with VoIP products from networking giants like Cisco and Avaya. Microsoft hopes to establish an edge against them by integrating its server with widely used products such as Exchange 2007 and enabling unified services.

Microsoft planned to make the announcement about the new phones and the qualification programme today at WinHEC (Windows Hardware Engineering Conference).

Monday, May 21, 2007


Video conferencing is a powerful communications tool in the modern business world. The ability to share important business discussions with body language and facial expressions delivers enormous benefits compared to any other conferencing media. In many ways, video conferencing has truly become “the next-best thing to being there.”

Many Fortune 500 companies are frequent users of video conferencing solutions based on Video MCU (Multimedia Conferencing Unit) technology along with ISDN-based networks and video terminals. However, the expense of these systems often limits the deployment of conferencing technology to room-based systems in each corporate location. Video MCU products are typically tight, proprietary integrations of a conferencing application and video processing hardware. Video MCU solutions limit third-party feature enhancements, and also limit the reuse of the video processing resources with other applications. The result is a relatively expensive single-service solution with limited flexibility and scalability.

RadiSys Convedia Media Servers are bringing video application development into the Internet era. Convedia Media Servers are purpose-built to economically deliver the DSP-intensive video media processing capabilities essential in next-generation IP video conferencing solutions. Service providers and application developers, using familiar Internet technologies such as SIP and XML scripts, can now develop video conferencing applications to control Convedia’s advanced video bridging, streaming, and transcoding features, including multi-image display options and continuous presence. This “best-of-breed” approach not only reduces the overall costs for a video conferencing solution, but also facilitates the reuse of Convedia’s media processing capabilities across any IP-based audio or video telephony application.
Video codecs supported: H.263, MPEG-4*
Video bridging, switching, and mixing
Video conference recording and playback
Video transcoding and rate matching*
Advanced continuous presence*
External video media storage
Open standards-based control interface based on SIP and MSML/MOML facilitates integration with videomail application servers
Software-only upgrade to existing RadiSys Convedia Media Server platforms
Interoperability with existing ISDN-based terminals or emerging 3G-H324M mobile video terminals can be achieved through appropriate video gateway devices. When deployed with any QoS-enabled IP network (such as an IP VPN or an MPLS backbone network), video conferencing quality is comparable to existing ISDN-based solutions, at a fraction of the initial capital and ongoing operational expense. The result is an improved ROI, which will drive the economic migration and service benefits of video conferencing solutions out of the conference rooms and towards desktops and 3G mobile phones.

New XML Interface for Web Conferencing Development

WiredRed Software says that they are now offering an XML-based web services software interface for its e/pop Web Conferencing software. e/pop Web Conferencing offers features that include multi-party audio and synchronous video conferencing, remote control, plus desktop, application/document sharing and dynamic PowerPoint presentation sharing.

The interface will allow developers to build web conferencing solutions and integrate this functionality into a variety of applications such as workflow, document and content management, customer-facing CRM solutions, web portals, and ASP offerings.

The ability to integrate web conferencing and communications into traditional business applications and ASP offerings built on the .NET, XML and web services architecture enable organizations to eliminate the cost of expensive service-based web conferencing offerings while leveraging existing network investments.

NetSalon Software Development Corporation, a provider of software applications for the direct sales industry, chose WiredRed's e/pop Web Conferencing SDK to add web conferencing, desktop sharing with remote control, and multi-party video conferencing to its contact management and sales automation services.

The e/pop Web Conferencing SDK allows developers to build a scalable enterprise product with industry standard security. The resulting conferencing app will let users control video and audio settings and includes full-screen video with 640 x 480 resolution. In addition, conference hosts can change all of the video properties, including screen size and quality either conference-wide or on an individual viewing basis.

e/pop Web Conferencing is based on the XML standard to provide RPC remote procedure calls from virtually any development environment or platform. Its WSDL-compatible interface supports most development platforms, including C++, C#, Java, and also many platforms, such as Windows, Linux, Solaris and Unix.

e/pop Web Conferencing is compatible with standard audio-visual peripherals including microphones, headsets and USB web cameras. It also supports industry standard algorithms for both audio and video codecs. This ensures that the web conferencing platform is both cost-effective and reliable.

Supported video standards include H263, H264+ and MPEG4 and audio codes G7.x, PCM, ADPCM, VCELP and LPC. The e/pop Web Conferencing API provides support for the highest security standards for encryption and authentication. Security options include: SSL/TLS, RC4, DES, 3DES, AES and RSA.

XML Integration in ADO.NET

The objective of this session is to introduce developers to leveraging the XML features and support in ADO.NET.

These are some of the key topics that will be covered in this presentation:
Accessing the output of executing ADO.NET commands as XML streams
Persisting ADO.NET datasets as XML
Using XML data to populate ADO.NET datasets
Using the Microsoft .NET Framework XmlDataDocument class to
manipulate the data in an ADO.NET dataset using XML
DOM properties and methods
Synchronizing an XmlDataDocument object with an ADO.NET dataset
Practical applications of XML features implemented in ADO.NET
The code samples presented in the slides of this presentation will be written using Microsoft Visual Basic .NET.

Presentation to be given by:
Karthik Ravindran: Karthik has been with Microsoft for more than two years. He is a Developer Support Professional in the XML Web Database team, and is the PSS MSXML Beta Product Lead. He holds a master's degree in Information Technology, and the MCSD & MCP+SB (Site Builder) certifications.
Karthikeyan Ponnusamy: Karthi has been with Microsoft for two years. He is a Developer Support Professional in the XML Web database team, and is currently the PSS Web Database Content Lead. He holds a master's degree in Engineering, and MCSD certification.

Friday, May 18, 2007

Data, text and structure mine XML and relational data with XML Miner

XML Miner is a system and class library for mining data and text expressed in XML, extracting knowledge and re-using that knowledge in products and applications in the form of fuzzy logic expert system rules. XML Miner can also be used as a full featured, low cost Business Rules system.
  • Use it to predict numeric values, categorise and classify data, infer the relevance and topics in text, and to mine the structure of XML documents.
  • XML data is everywhere, can be easily generated from any data source, but can be unstructured and sparse. XML miner is the first data mining tool to mine any data that can be expressed in XML.
  • XML Miner is configured via XML, reads XML, and creates results in XML using our Metarule schema.
  • XML Miner performs both Supervised learning of numeric, categorical, structural or textual values to a given numeric or categorical output and Association learning, where a data set is searched for all useful relationships between data or structural values.
  • You can convert Metarule to easily understood English language if...then rules using an XSL transform we supply, so you can see what's been discovered.
  • You can apply Metarule rules to new data, either supplied directly or embedded in an XML document and have the results available for use in your programs or embedded into a copy of the source XML.
  • XML Miner is standards-based and compatible with other standards-based tools.
  • XML Miner comes with development tools easily used with Visual Studio .NetTM or any JavaTM development environment
  • XML Miner integrates text mining seamlessly so that blocks of embedded text can be handled at the same time as numeric and categorical data.
  • XML Miner is implemented as .Net and Java class libraries. You can create products for any platform

XML Miner is a completely new development in data mining systems. Although it can perform the same kind of processing as other data mining systems, it is the first and only product that can also mine semi-structured data sources such as XML. It unifies into a single system a variety of different functions:

First of all, it data, text and structure mines semi-structured data expressed in XML, all at the same time.

You can specify nodes in a document for text mining, nodes for conventional numeric data mining, and structural elements - and then mine them all at once so that the resulting model combines knowledge found in all those diferent ways.
Secondly, XML Miner describes the result of the data mining, the model of what it has found, as fuzzy logic if..then rules using our language Metarule.
Using our editor or a simple transform we supply these can be displayed and edited as English language rules - so that the relationships discovered can be clearly understood.
Thirdly, we supply a run-time processor as part of Xml Miner that you can use to evaluate new data, whether supplied in XML, or programmatically, and which you can build in to your applications.
The metarule language, as well as supporting the output of the data and text mining algorithms, has full support for fuzzy logic inference, fuzzy arithmetic, algebraic functions and text handling functions. With the editor and the runtime processor it makes a fully functioning, emeddable business rules system.
Fourthly, the rule sets, whether created by the user or by Xml Miner, can be tested for coverage by our consistency checker called Lacuna.

A report is generated detailing any lacunae, i.e. any combinations of input values that result in the rule set not generating an output value, so that the users can be sure that the rule set covers all the circumstances that can arise.
Finally, we supply an integrated development environment that permits you to do all the above via a simple user interface. You can display source XML, locate via XPath expressions the data nodes you want to mine, train the sytem to create rule sets, test the rule sets on your own data, create your own rule sets, and load and store rule sets and data files.

The same IDE can be used to run demo examples, process data remotely on our web service, or process data locally. You can choose the level of performance you want and purchase the appropriate license.

XML-RPC For C and C++

XML-RPC is a quick-and-easy way to make procedure calls over the Internet. It converts the procedure call into XML document, sends it to a remote server using HTTP, and gets back the response as XML.

This library provides a modular implementation of XML-RPC for C and C++.

XML-RPC For C and C++ is designed for Unix and is most tested on unix. As far as we know, it works on any reasonably standard unix.

There is also lots of code to make it work on Windows, but the fact is that it probably won't work out-of-the-box on your Windows system. Here is the Windows story.

[XML-RPC protocol ]

There is a Perl module to interface to XML-RPC for C and C++. Look in CPAN for RPC::Xmlrpc_c.

For information on using XML-RPC with other languages, see the XML-RPC Web site and the Linux XML-RPC Howto.

XML in C

XML is a base-language for expressing arbitrary structured data in text form. It consists of several modules: core syntax, meta-syntax, linking, style-bindings, and maybe more. Of these only the core syntax is common to all XML applications. Applications can choose to omit the other modules if they don't need them.

This text describes one possible core syntax, using flex/bison specifications. The most important additions relative to the XML-lang draft of 30 June 1997 include: automatically ignored newlines, attribute defaults, and boolean attributes.

Mining association rules from XML data using XQuery

In recent years XML has became very popular for representing semistructured data and a standard for data exchange over the web. Mining XML data from the web is becoming increasingly important. Several encouraging attempts at developing methods for mining XML data have been proposed. However, efficiency and simplicity are still a barrier for further development. Normally, pre-processing or post-processing are required for mining XML data, such as transforming the data from XML format to relational format. In this paper, we show that extracting association rules from XML documents without any pre-processing or post-processing using XQuery is possible and analyze the XQuery implementation of the well-known Apriori algorithm. In addition, we suggest features that need to be added into XQuery in order to make the implementation of the Apriori algorithm more efficient.

XML: Designing XML Internet Applications

Designing XML Internet ApplicationsAuthors: Michael Leventhal, David Lewis, and Matthew Fuchs
Designing XML Internet Applications. By Michael Leventhal, David Lewis, and Matthew Fuchs; with contributions from Stuart Culshaw and Gene Kan. The Charles F. Goldfarb Series on Open Information Management. [Subseries:] The Definitive XML Series from Charles F. Goldfarb. Upper Saddle River, NJ: Prentice Hall PTR, [May] 1998. Extent: xxxii + 582 pages, CD-ROM. ISBN: 0-13-616822-1. Price: $44.95 U.S./$63.00 Canada. See also: the main bibliography entry and the Prentice Hall SGML Series Page.
Volume Description[Provided by the authors.]
Designing XML Internet Applications is divided into five parts.
In the first part we will introduce you to the XML universe. Here you will find a discussion of the role of XML in the internet and a quick-start on the XML recommendation and XML tools. We don't assume prior knowledge of either XML or SGML but our task here is not to provide an extended tutorial or reference on the language syntax. What we do do is develop the perspective of the XML internet application designer and provide any background that is needed to comprehend the subsequent chapters.
The next three parts consist of a series of projects using XML in actual internet applications. Working through the projects the reader will gain concrete experience in the design of XML applications, DTDs, and programming. We also delve into standards related to XML and the internet wherever relevant.
The first project spans five chapters as the construction of several types of components is involved including a bulletin board, forms processing tools, a search engine, and transformation filters.
Most of the work is done in Perl and the approach is less rigorous than that used in subsequent projects. Our intention here is to introduce XML programming in the most simple and "exposed" form possible.
We have chosen to use Perl in this first part for various reasons. It is the closest thing we know of to a lingua franca for internet programmers, it is extremely compact allowing us to construct complete examples in relatively few lines of code, and, most significantly, Perl is the most versatile XML scripting language.
The second project implements SGML/XML email and digs into the topics of entity management, catalogs, MIME, and full- scale SGML/XML parsing. Code is presented in Perl and C++.
Lest the reader think we are Perl bigots the third project plunges us into Java and XML, building an application based on the Document Object Model and making use of a Java XML parser API. Java is the language in which most of the new XML internet infrastructure is being built.
The fifth and final section of the book takes a rigorous, formal look at the role of XML in software architectures and agents based on the paradigm of negotiation.
Full source code for all the projects has been included on the CD-OM as have all the public domain tools used in the book.

Thursday, May 3, 2007

Accessing VoIP Destinations

Accessing VoIP Destinations

As the proliferation of VoIP phones has skyrocketed, there is ample reason to consider the market for outbound and inbound VoIP access when designing IVR applications. From the start, Voxeo has been ready. Herein, we will walk you through the process for dialing to and from a VoIP phone to access your XML applications, and detail the offerings that have been tested to work with the Voxeo platform.

Bear in mind, there are some rather important caveats to using the Voxeo SIP services that you should be aware of before you begin.

  • All Voxeo platforms, (Motorola Voicexml2.1, CCXML, Callxml), support the SIP protocol for bridged transfers
  • Token-triggered outbound calls via HTTP are enabled for SIP calls.
  • Any 'true' SIP phone can dial the Voxeo network.
  • The Voxeo outbound dialing feature is not enabled for all SIP phones/providers.


Voxeo has found that the easiest to use softphone on the market is the Pulver Communicator. The Communicator's setup and configuration is much less cantankerous than other free softphones, and its integration with instant messenging clients, along with a full arsenal of other features, (video, multiparty conferencing, and phone number blacklisting, to name a few) makes the Pulver Communicator a natural choice. Voxeo has partnered with Free World Dialup, the network residing beneath the Pulver Communicator, allowing for easy application access from anywhere on the globe

Inbound VoIP Dialing

Each application provisioned through the Evolution Site site can be SIP-enabled, by clicking on the application detail screen, and selecting "Add 800+PIN/VoIP Number". This will bring up a new subsection to the application detail titled "calling from VoIP", where a new number will be added that looks something like this:


As easy as that, you can plug this destination number into yourPulver Communicator softphone to ring the voxeo application. This start sequence is specific to the Pulver Communicator/FWD. However, any SIP softphone can call Voxeo development applications by dialing:

(application PIN)

Obviously, you will want to ensurethat the proper firewall rules are in place for these calls to function correctly.

Outbound VoIP Dialing

When making an outbound PSTN call, either HTTP token based, or via a 'transfer' or 'call' element, the default syntax assumes a PSTN bridged transfer.However, when placing a SIP call, we need to change our syntax appropriately, and add a 'sip' prefix to the string:


SIP: sip:


SIP: sip:


SIP: sip:
**'" name="line_1"/>

Predictably enough, this applies to token-based calls as well, regardless of the platform:

As this offering is still relatively new, Voxeo has not tested all services and providers with our VoIP offering. As such, results may vary upon your initial efforts to place an outbound call to your SIP phone from a Voxeo application. However, if you do encounter problems with a particular service, just let us know! If we can, we will help out where possible.

We can say for certain that most of the services that work with Free World Dialup, (X-10 softphone,and the Pulver Communicator), work smashingly with the Voxeo platforms, and shouldn't encounter any errors. If you are calling a non-Pulver softphone/network, then you will likely need to change the prefix::

Using the "" works just dandy to connect to the FWD network. Furthermore, FWD has a Vonage interconnect, as well as many more using a ** nomenclature. Just as **869 will get you from FWD to Voxeo, **2431+any-vonage-number will get you to Vonage, **8981+any-packet8-number will get you to Packet8, etc. If you are using another provider, you would do well to check out the listing of these interconnects to see what prefix you will need.

Local International Numbers

In addition to providing free softphone access for our developers, voxeo has recently unvelied a new offering that is bound to prove useful to our Community Members. Thats right, voxeo now offers local access numbers to a broader spectrum of players in the worldwide market. This means that instead of dialing an 800+PIN code to access your applications, you can dial a free *local* number to access our application PIN system!

Voxeo currently has local access numbers deployed on a trial basis for the following markets for our 800+PIN system:

Local Access Number Locale
+44-20-7043 7144 London, UK
+34-93-2395107 Barcelona, Spain
+39-06-43408608 Roma, Italy
+972-2-649 9751 Jerusalem, Israel
+372-6-976953 Tallinn, Estonia
+55-21-3523 4238 Rio de Janeiro, Brazil
+1-617-507 7122 Boston, USA

Throughout the rest of the year, we will be adding additional direct-dial numbers for different locales available on the system, so remember: whichever locales receive the most requests will be first in line; make your voice heard!

VOIP: What is CCXML?

What is CCXML?

CCXML - or Call Control XML - is the W3C standard markup language for controlling how phone calls are placed, answered, transfered, conferenced, and more. CCXML works hand-in-hand with VoiceXML to provide a 100% standards and XML based solution for any telephony application.

Voxeo supports CCXML in all of our VoiceCenter and VoipCenter products. Voxeo also sells an OEM C++ source code CCXML engine. Our CCXML products have routed over 1 billion calls since commercial introduction in 2002.

Below you will find a great introduction to CCXML by RJ Auburn, Voxeo's CTO - who is also the editor and chair of the CCXML standard. In addition, you'll find a CCXML executive briefing that details the benefits of CCXML. Finally, you can review Voxeo's complete CCXML reference guide and tutorials here.

Introduction to CCXML

RJ Auburn
Chief Technology Officer, Voxeo Corporation
Editor and Chair, W3C CCXML working group

As editor of the new CCXML specification I am proud to report that the W3C has just released the first working draft of CCXML, a language to provide Call Control support for telephone applications.

What is Call Control?

Newton's Telecom Dictionary, 16th edition, defines Call Control as "the term used by the telephone industry to describe setting up, monitoring, and tearing down telephone calls". Fundamentally, Call Control is session control for telephone calls.

What is CCXML?

Traditionally, Call Control has required interaction with and understanding of telephony API's which often change from one platform to another.

CCXML is the "Call Control eXtensible Markup Language". It is an XML based language that can control the setup, monitoring, and tear down of phone calls. CCXML allows the industry to leverage the strength of Web platforms and technologies to intelligently control calls on and off the telephone network. Additionally, CCXML will create a high-level industry standard for Call Control that can run over any telephony platform.

Why not build Call Control into VoiceXML?

VoiceXML was never designed to support advanced Call Control features - it was designed to be a dialog control language and it does that quite well. While VoiceXML does support basic Call Control features via the tag, those features are in fact too basic for many telephony applications. Because of this limitation, vendors looked at adding Call Control to VoiceXML using several different approaches. Some companies added robust Call Control support by extending VoiceXML while others created their own Call Control languages such as CallXML from Voxeo. While these solutions provided enhanced Call Control support they were incompatible with each other and did not address all of the Call Control scenarios reviewed by the W3C.

VoiceXML controls the presentation of media inside of calls. It uses a model based on forms and transactions that occur in a linear fashion - a model that works very well for user driven voice interfaces. Call Control uses a model based on events and commands that can occur at any time. The fundamental differences in these models made it very difficult - if not impossible - to deliver robust Call Control inside of VoiceXML itself.

Additionally, many W3C members and telephone industry leaders wanted a language that could be used outside of VoiceXML itself. While only some phone calls require automated voice interaction, every phone call requires Call Control. As a result, CCXML could end up being used and supported by everything from PBX's to the telephone switches that run the phone network itself. Many of these telephony platforms have no need or support for the things VoiceXML itself can do.

What does CCXML allow you to do?

There are a number of features that VoiceXML currently can't supply that CCXML will:

  • Support for multi-party conferencing, plus more advanced conference and audio control. Any telephone conferencing application requires such features.

  • The ability to give each active line in a voice application its own dedicated VoiceXML interpreter. Currently, many VoiceXML platforms initiate a second call or "call leg" to transfer a call from an automated VoiceXML platform to another telephone user. The second leg of a transferred call on these platforms lacks a VoiceXML interpreter of its own, limiting the scope of possible applications that can occur on that second leg.

  • Sophisticated multiple-call handling and control, including the ability to place outgoing calls at any time, initiated outside of the VoiceXML platform.

  • Handling for richer and more asynchronous events. Advanced telephony operations involve substantial signaling, status events, and message-passing. VoiceXML does not currently have a way to integrate these asynchronous "external" events into its event-processing model.

  • An ability to receive events and messages from systems outside of the CCXML or VoiceXML platform. Interaction with an outside call center platform, calls started asynchronously from the VoiceXML platform, and communication between multiple "clustered" VoiceXML or CCXML platforms all require event interaction from one platform to another.
CCXML allows developers to write advanced applications that require these features. Examples of such applications include
  • "Follow me, Find me" applications that find the person you are trying to call by dialing their cell phone, home phone, and office phone in parallel.

  • Call center applications that intelligently gather information from the caller and then pass that information on to the call center agent.

The W3C Voice Browser Working Group decided to tackle Call Control and came up with a set of comprehensive requirements that address the Call Control needs of almost all voice applications. After reviewing those requirements several proposals were submitted. CCXML is the result of those proposals.

What does CCXML bring to VoiceXML?

CCXML adds robust Call Control support to VoiceXML. However CCXML could also be used with other dialog systems such as a traditional IVR (Interactive Voice Response) platforms created before VoiceXML was available.

One critical thing to understand is that CCXML is not a media/dialog language like VoiceXML. It only provides support to move calls around and connect them to dialog resources. CCXML does not provide any dialog resources on its own. (Note: A dialog resource is anything that interacts with a caller via voice, such as a VoiceXML platform or even a second caller at another location.)

What does CCXML look like?

Let's create a CCXML application. The following example was written on the Voxeo CCXML platform implementation. You can access Voxeo CCXML platform for free by signing up at

The First Step

Lets start with the equivalent of a hello world application that conditionally answers the phone based on your caller id, plays a VoiceXML dialog and then hangs up. Being able to conditionally answer a call is one of the new features that CCXML brings to VoiceXML applications.

To start off we create a XML tag and a tag for the document. These are required in all CCXML documents.

Event Handlers

CCXML is based on a state machine model.

In general, a state machine is any program that stores the status of something at a given time and can operate on input (ie: telephony events) to change the state of the "machine" and can optionally cause an action to occur. State machines are used to develop and describe specific device or program interactions.

To summarize, a state machine can be described as:

  • An initial state or record
  • A set of possible input events
  • A set of new states that may result from the input
  • A set of possible actions or output events that result from a new state

In their book Real-time Object-oriented Modeling, Bran Selic & Garth Gullekson view a state machine as:

  • A set of states
  • A description of the initial state
  • A set of input events
  • A set of output events
  • A function that maps states and input to output
  • A function that maps states and inputs to states called a state "transition"

There are a number of ways to represent state machines, from simple tables, to C switch and case statements, to graphical design tools. CCXML uses XML tags to represent the state machine which will control one or more telephone calls.

The CCXML tag contains all the event handlers, or "transitions" for our call-control application. In CCXML you write an event handler for your application and then the handlers transition tags will receive all the matching events that occur during a call.

We Are Now Connected

Next we add a tag for the call that we just answered. We are looking for the "connection.CONNECTION_CONNECTED" event. This event will only come into the CCXML platform once the call has been connected.

Running a Dialog

Let's start a VoiceXML dialog script from the connected call event handler on the call we are connected to. We do this with the tag and by specifying the URL source of the VoiceXML document we want to run. Once we do this the CCXML platform will connect the call to a VoiceXML resource and play the script to the caller.

Here is the content of hello.vxml:

1.0//EN' '' >

Hello World.

Ending a Dialog

We now add the tag to catch the event that indicates the VoiceXML dialog has ended. We do this by catching the "dialog.exit" event.


Next we add the tag to the dialog exit handler to disconnect the caller from the CCXML platform. We will also write to the log using Voxeo's tag.

Ending the Call

We are almost done with our first CCXML script. We only need to add some clean up code to exit the CCXML interrupter. We do this by adding a tag to catch the "call.CALL_INVALID" event:


The End Is Nigh

Finally we add a handler for the call_invalid event that occurs when a call ends, including an tag to leave the CCXML platform:

Congratulations, you have now written your very first CCXML application! If you would like to learn more about CCXML there are a number of tutorials that will help get you up to speed on of CCXML that you can access at

CCXML Executive Briefing

Companies are recognizing the important role that advanced call control functionality plays in effectively communicating with customers, employees and partners. The challenge is finding a cost-effective method that leverages existing Web and data systems investments to delight customers and deliver significant returns. Using a band-aid approach to upgrade older generation, proprietary Interactive Voice Response (IVR) and contact center systems is very expensive and ineffective in the long run. Widely popular, open standards VoiceXML solutions are a big step in the right direction...

Sunday, April 29, 2007

Windows to Ubuntu Transition Guide



Alright, so you have successfully installed Ubuntu Linux, but now what do you do with it? You are in the right place. I am going to get you started with a guide on how to use your new Ubuntu system. This transition guide is targeted at existing Windows users and will show you how to do program installations, a little system configuration, but primarily highlight some Windows "replacement" programs for common applications you can't live without. This guide's intent is to introduce you to equivalent programs to what you are accustomed to and, hopefully, to cover a good amount of what you might want in a new install. I am basing the content on what I have personally experienced, email feedback from my installation article, questions from the PC Mech Forums, and common topics from the Ubuntu Forums. Hopefully this will answer a lot of questions you may have before you ever have them.

There is no prior Linux experience needed to follow anything I will go over, however I am going to make the assumption you have at least played around in Ubuntu for a bit. I am not going to be covering the basics on how to use the interface, as it is quite similar to Windows. Here is a quick breakdown of the topics I will be covering:

  • Configuring and using Synaptic Package Manager to install applications
  • Installing common packages with Automatix
  • Essential desktop, office, and Internet applications
  • Playing movies and music
  • Games
  • Digital cameras, printing, and burning
  • Installing a PHP and MySQL enabled Apache web server
  • Development tools
  • Installing and configuring a firewall
  • Setting up remote desktop connection
  • Setting up a streaming music server

Since this article's intent is to be a beginner's guide to Ubuntu Linux, I am going to be using the graphical interface for pretty much everything. As experienced Linux users may know, and you will soon find out, everything we are going to be doing can be done much quicker through the command line. Of course, this is not very user friendly, and a very un-Windows way to do things, so again, we will be sticking to the Ubuntu GUI (Graphical User Interface).

As you are reading, please bear in mind that Linux is not Windows. At a high level they appear to operate basically the same, but they are fundamentally different. Just keep an open mind and I promise learning Ubuntu Linux will be well worth your time.

Windows and Ubuntu on One PC-By setting up your PC to dual-boot, you can easily take Linux for a test-drive.

"Linux rocks!" "No, it's lame--stick with Windows!" Visit any Web site or online forum where impassioned computer users debate the relative merits of operating systems, and you'll find endless disagreement. The only way to determine which operating system fits your needs is to run both on the same PC, configured for dual-booting. You also need to be able to access your data files from either OS, which is the trickiest part of the process.

Creating a dual-boot setup on a Windows machine is as easy as selecting that option when you install Ubuntu. As you switch between the two operating systems in your day-to-day work, you'll be able to assess for yourself the killer features, incompatibilities, and showstopping flaws that make one a better choice than the other.

On a dual-boot system, Linux and Windows reside on separate disk partitions, each of which is formatted differently. Even though the file systems are incompatible, most recent versions of Linux can at least read files on Windows XP's NTFS partitions, though this may not be enabled by default. Few Linux distributions can write files to an NTFS partition right out of the box, and the reliability of this function hasn't yet been proven, so trust it at your data's peril. In addition, the software required to write files from Linux to NTFS drives is difficult to download and install.

Windows, conversely, lacks the native ability to read and write files on any of the several Linux file systems. The nifty and free Ext2 Installable File System for Windows permits Windows XP to read and write in the Ext2 and Ext3 file systems many Linux distributions use (it doesn't work with the ReiserFS file system, however). While this is handy, especially if you spend most of your time using Linux and you keep your files there, I recommend another option: creating a separate partition for your data that uses the older FAT32 file system, which both Linux and Windows XP can read from and write to. In fact, FAT32 has been included with every version of Windows since 95's Service Release 2.

FAT32 lacks the user-access security features of Linux's Ext2/3 and Windows' NTFS, but creating a separate FAT32 partition for your data allows you to install or upgrade your operating systems without having to back up or restore your data files. It also lets you read and write that data with minimal add-on downloading and configuration. If you need some assistance in resizing your existing partitions to create a new FAT32 partition, look no further than the free Partition Logic utility.

Saturday, April 28, 2007

Basic vi Commands

Edit Commands
Text Object Change Delete Copy
1 word cw dw yw

2 words, not counting punctuation

2cW or c2W 2dW or d2W 2yW or y2W
3 words back 3cb or c3b 3db or d3b 3yb or y3b
1 line cc dd yy or Y
To end of line c$ or C d$ or D y$
To beginning of line c0 d0 y0
Single character r x or X yl or yh
Five characters 5s 5x 5yl

Movement Commands
<-,-v,-^, " src="../chars/rarr.gif">

h, j, k, l

To first character of next line +
To first character of previous line -
To end of word e or E
Forward by word w or W
Backward by word b or B
To end of line $
To beginning of line 0

Other Operations
Operations Commands
Place text from buffer P or p
Start vi, open file if specified vi file
Save edits, quit file ZZ
No saving of edits, quit file :q!

Text Creation and Manipulation Commands
Editing Action Command
Insert text at current position i
Insert text at beginning of line I
Append text at current position a
Append text at beginning of line A
Open new line below cursor for new text o
Open new line above cursor for new text O
Delete line and substitute text S
Overstrike existing characters with new text R
Join current and next line J
Toggle case ~
Repeat last action .
Undo last change u
Restore line to original state U

Hot Vim Plugins

See for details.

In Chinese!

Vim 实用技术


Vim 实用技术,第 1 部分: 实用技巧

本系列文章分三部分详细阐述了 Vim 的使用技巧、插件、定制。第一部分主要是深入分析了 Vim 的使用。

Vim 实用技术,第 2 部分: 常用插件
第一部分介绍了一些基本的 Vim 使用技巧。掌握这些技巧可以很大地提高编辑效率,但是 Vim 的强大功能并不仅限于此。Vim 还可以通过“插件”来进行功能扩展。精确地说,是通过脚本来进行扩展,脚本类型有插件、语法加亮、配色方案、文件类型检测等多种。大部分的脚本都是由 Vim 的用户写的,解决了用户身边的问题,使 Vim 变得更加有用。本章将介绍最常用的一些脚本,其中除了一个属于“语法加亮”脚本外,其它都属于“插件”类型。关于如何写脚本的一些基础知识将在下一部分进行一些介绍。

Vim 实用技术,第 3 部分: 定制 Vim
前面两部分讲的都是如何使用现有的 Vim 系统,本部分则会通过实例来讲如何定制 Vim 的行为。良好的定制可以让使用 Vim 变得更为得心应手;同时,在掌握了基本的定制之后,也许你就会想进一步写一些自己的 Vim 脚本,从而真正地成为一个 Vim 专家。

[Please Click the links to see the details...]

C++ vs Java vs Python vs Ruby : a first impression


Executive Summary

I am a language agnostic journeyman programmer. I am not a fan of a particular language (I almost said 'fanboy') but thats a bit inflammatory). I just want to write useful programs and have fun doing it. I know C++ and Java pretty well. I did some beginner work in Python and Ruby. I then came up with the following conclusions. But before you flame, read the whole article.

  • C++ vs Java
    Java garbage collection is the big productivity gain
    Java is significantly slower than C++
    C++ is (much) harder to code correctly than any of the others
  • Java vs Python/Ruby
    Python/Ruby interpreted execution and dynamic typing are big productivity gains over Java.
    Python/Ruby are slower than Java
    Python/Ruby programs need less extraneous scaffolding (cleaner code)
    There are two important tradeoffs : [interpreted vs. compiled] and [static vs. dynamic typing]
  • Python vs. Ruby
    nearly equivalent


When running various distributions of Linux, I always ran into the choice of KDE or GNOME. There are plenty of advocates on both sides, but there was no overriding authority. Then recently Linus Torvalds came out with a definitive opinion. He took the unequivocal position that KDE is best. Not that he is necessarily the final arbiter of user interfaces, but at least he provides a strong datapoint, and since he is smarter than me and since all the other opinions seem to come from biased sources, I can now pick KDE and feel better about it. Paraphrasing the old IBM criteria, 'no one was ever fired for following a Linus directive'. Heh, after all that it turned out that I wanted to use Ubuntu which works best with GNOME so I ended up with that for now. So 'most practical' won out over 'best'.

In the meantime I realized I needed to learn a new language and the current buzz is Python and Ruby. Again I couldn't find a definitive answer of which one is best. From all the buzz, I came up with a vague impression that Ruby is more pure and is set to win in the long run, but that Python is currently more practical for now. And Google uses Python, which is a significant datapoint. They aren't idiots over there.

To see what I could figure out myself, I decided to code up something in Java, then port it to Python and Ruby and see how I felt about each, and try to identify where the big wins are for each language.

One caveat. If something significant is missing from a language, like garbage collection, then I don't want to hear a response that says "well, if you use XYZ unsupported library, or you do ABC convoluted technique, then you can do the same thing in [put language name here]". I am trying to evaluate the STANDARD here, since of course you can probably do anything in any language including assembler if you work hard enough. And the problem with using a nonstandard library is not just the extra integration work, it's that you are basing your code on something that may fall by the wayside later on and then you are stuck. Sometimes it's worth it but that has to be proven on a case-by-case basis as far as I am concerned.


I started in C in 1985, learned C++ in 1990 (Zortech C++) and have been using it ever since. I learned Java in the mid-90's when it was first coming out, and found three big win's for Java over C++: Garbage collection, portability and simplicity. Garbage collection and simplicity created big productivity gains, and portability is portability. Not having done a garbage collected language before, the productivity gain was readily apparent. The simplicity of Java over C++ was really nice. When coding C++, I needed Meyer's Effective C++ on my desk at all times to be sure I wasn't invoking some weird type coercion or copy constructor/assignment operator anomaly. And don't even start with templates. With Java I never needed that because it is just simpler. And the Java libraries were more comprehensive and string handling was easier. So in general I was more productive coding away in Java. I still liked C++ but it seems that when programming C++, the fun is in figuring out the language and library , like solving a puzzle. That leaves less time to spend on solving the application domain problem.

the code

The attached code samples are implementations of a Red-Black tree algorithm adapted from descriptions in "Algorithms in C++", Sedgewick and "Introduction To Algorithms",Cormen/Leiserson/Rivest. I picked this because it was short but had some complexity.

code notes and disclaimers:

  • commenting is sparser than usual to avoid obscuring code
  • I probably made some convention errors in Python and Ruby due to ignorance of the proper idioms
  • all these programs compile and/or run without warnings and output the same result
  • I believe the programs to be correct. there may be bugs but if so they are in all 3 versions
  • Java 5.0 SDK,Python 2.4, Ruby 1.8.3, C++ Microsoft Visual C++ 2005


It was surprisingly easy to port the Java code to Python and then port the Python to Ruby. A lot of it was regular expression search and replace, getting some naming conventions right and adapting to a few language differences. During the porting process, the two big gotchas I ran into were Python block indenting errors and Ruby's horrible compiler diagnostics.

Porting the Java code to C++ was much more a hassle. I attempted to make use of as much static type checking mechanisms as I could. In Java I used generics for the tree, and in C++ I used templates for the container and 'const' where appropriate. The big gotchas on porting to C++ were:

  • The dichotomy between primitive types and objects in C++ is much more pronounced even than Java (and Java is worse off than Python or Ruby). This dichotomy makes it hard to write a class that supports both primitives and objects. My implementation might need some fixups to work with objects rather than 'int'.
  • Java,Ruby and Python all use a consistent reference only scheme to refer to objects which are always on the heap or equivalent. In C++, you can have a statically declared objects, a pointer to an object, or a reference to an object, each with features and limitations. A C++ 'reference' is not the same thing as a reference in the other languages. C++ really wants you to use pointers. These alternatives means that when you write something in C++ you have to come up with a consistent strategy for using the 3 types of object access, and your strategy might not be the same as what others prefer. There is 'more than one way to do it'.
  • The lack of built-in mechanisms or even just conventions for operations that should be common across types means you have to make things up. Like converting a type to string representation. All the other languages have support of one kind or another but in C++ you have to make up your own convention
  • Maybe its just me, but C++ always leaves you wondering what you might have done wrong. Its hard to tell. If you read Meyer's Effective C++ you see that there are numerous detailed infrastructure things like constructors and assignment operators that you have to get exactly right or things fail at runtime. C++ is really hard to get right, and I never feel totally secure that I did it properly
In my opinion (and I have written a lot of C++), use C++ only where you have to for compatibility or performance reasons, or where you arbitrarily decide that you would rather use C++ because its more fun because its harder. As Tom Cargill (a noted C++ guy) said, "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?".

python block indenting

It took me a while to get my editor (JEdit) happy with Python and getting to not use tabs. Fortunately I never screwed up the file so bad that the code didn't work but I always had an unpleasant uncertainty about the indentation simmering in the background. Some (or all) of this may be prejudice. I really liked braces better than either Ruby Do-End or Python indenting, at least when I was coding. On the other hand, a properly indented Python file looks much much cleaner and is easier to read than any of the others because you don't need all the block closing symbols. However the explicit 'self' argument makes it look less clean than it could.

ruby syntax errors

Many of the compiler diagnostics I got during the Ruby porting simply said "syntax error" and gave the line number for the last line in the file. Great. I spent a lot of time doing binary searches on my code to find the error source.

The visitor pattern

One thing I did differently in each language was try to adapt a 'Visitor' pattern (for traversing the tree) to the preferred idiom for each language. You could of course simply code up a Visitor class that is nearly identical for each language, but instead I did the following.

  • Java : one scheme : an anonymous class implementing a predefined interface.
  • Python : two schemes : a named class similar to Java and just a named function passed in as a parameter.
  • Ruby : two schemes : a lamba anonymous function, and a Ruby block implementation

The Java and C++ approaches give you static type checking but takes a lot more cruft to get going. I found the Python named function parameter very convenient. But it doesn't carry any state so if you need state then you use a class. Surprisingly, I found the Ruby lambda easier to understand and implement than the Ruby 'block'. That is because my traversal algorithm is recursive, and the lambda just gets passed around as a parameter (like the python named function parameter). I didn't exploit the full potential of a lambda closure.

The Ruby block scheme (pun not intended) requires some tricky syntax in the recursive calls, and I could not find a good explanation of how to handle recursive use of blocks in the Ruby documentation. I found a single web hit with an example and after fiddling with it I got it to work. I think I understand them now but it is still a bit fuzzy. I mean, I know what to do now but it takes some concentration to figure out what exactly is happening and why the code looks like it does. I found that viewing a Ruby block as a co-routine (per the documentation) and not as a subroutine to be the best way to understand the whole thing.

All that said about the Visitors, I am a Python/Ruby novice so possibly I did things the hard way :)

interpreted vs. compiled

There has always been this tradeoff. In fact, the Python/Ruby vs. Java performance controversy sounds a lot like the C/Assembler/Forth discussions in the embedded systems world of the early 1980's. Forth was interpreted, it didn't need a compile cycle and it had (supposedly) productivity enhancing features that C didn't have. Development cycles were much shorter with Forth. Performance was not as fast as C or assembler but was close. The drawback of Forth was the weirdness of the language. C won out and Forth went to the dark corner of mostly forgotten languages.

Interpreted languages give you a much quicker development cycle, especially on big programs. There is no doubting that. Its simply a tradeoff of execution speed vs. productivity. Some applications need the speed. I think it is a premature optimization to say the "I like C/Java better than Python/Ruby because they execute faster". Interpreted is better if you can get it. When I was testing the code I experienced the advantage of interpreted. I didn't really measure performance but other sources show the differences. But since Python/Ruby seem to interface to C/C++ pretty readily, I would be very comfortable working in the interpreted world and descending into the netherworld of compiled C/C++ when required. Yes, Python is actually compiled for a VM but you don't have an explicit compile operation so it acts to the user like an interpreted language.

static vs. dynamic type checking

Ok, I like the productivity increase provided by dynamic typing because it eliminates a lot of scaffolding. I found it quite interesting to see errors pop out at runtime that would normally be compile time in C++/Java. These runtime errors were obviously influenced by the paths taken in the test program (or how far it got before it barfed). For a given run, I clearly wasn't seeing all the instances of this class of errors as I would have with static type checking.

Coming from a statically typed language background, my gut says that dynamic typing creates a risk. The Python/Ruby bloggers say that if you just unit test properly, then there is no problem. Brucke Eckel has a well reasoned essay on the issue. I would argue that expecting unit test to catch typing errors has two issues:

  • in a really big system, its hard to test exhaustively
  • testing for type correctness makes the programmer do the work that a computer could do

We static typers may be wrong. I had a similar experience moving from PVCS to Subversion version control. Oh, My, God, no locking? The code will be completely ruined in a week. But it turned out to be a non-issue and Subversion added so much less friction to the development cycle that productivity was improved maybe 10%. The collective good experience overrode the predjudice based theoretical 'proof'. The same argument can be made for dynamic vs. static typing.

I wouldn't mind a separate 'lint' tool for Python/Ruby (is it possible?). I use lint for C/C++ religiously. The whole compiled language community is moving towards more static type checking (Java Generics, for example) rather than less. Are they all idiots? (don't answer that)

My conclusion is that dynamic 'duck' typing is more productive, more pleasant, gives cleaner looking code but it incurs a risk that you will get a runtime type exception in your application at some later date. The risk is there, quit denying it.

the results

These results are meant to cover issues I noticed in the porting/testing I did. Not an overall evaluation. If I mention stuff that I didn't run into first hand, then throw that out.

C++ vs Java

  1. Garbage collection is THE big win for Java.
  2. Java simplicity over C++ complexity is a big win for Java.
  3. C++ is much harder to write and get right than Java or any of the other choices
  4. C/C++ is way faster than Java
  5. Language scaffolding requirements are similar for both
  6. C/C++ is the only way to go for low level systems programming.

Java vs Python/Ruby

  1. interpreted vs. compiled is a big productivity win for Python/Ruby
  2. dynamic typing is a big productivity win for Python/Ruby
  3. Java is way faster than Python or Ruby
  4. minimal scaffolding is a big productivity win for Python/Ruby. Makes programming more pleasant not to have to build all the infrastructure.
  5. mostly first class functions a big win for Python/Ruby.
  6. built-in lists/arrays and hashes/dictionaries a big win over Java [] and library based collections. Java 5.0 fixes some of this but in Java collections still seem tacked on rather than integrated.
  7. dynamic code loading in Python/Ruby is a big win. Yes you can do it in Java but again, the cruft.
  8. Ruby OO completeness over Java dichotomy between primitive types vs. objects is a big win for Ruby, less so for Python.
  9. There is some weirdness in Python and Ruby lexical scoping of names. The documentation for each has several warnings about edge cases where names don't bind in the expected way. This gives me a queasy feeling although in practice it may not matter. Another win for static type checking.
  10. Java 'Comparable' interface ugly compared to Python/Ruby built in comparison mechanisms that require only that a single function be implemented to get the full set of comparison operators. An example of excess Java scaffolding.
  11. lack of multiline comments in Python/Ruby was annoying
  1. static typing is a correctness win for Java, especially with Generics in 5.0. The C++/Java trend is toward stronger static type checking, not less
  2. dynamic typing is a productivity win for Python/Ruby at the cost of some risk
  3. interpreted vs. compiled trades off execution speed for shorter development cycles.

Python vs Ruby

none of these are that important

  1. Ruby's compiler/runtime error messages were mostly 'syntax error' with no help. in many cases almost useless
  2. Why does Ruby use rescue/ensure when the rest of the world has settled on try/catch/finally? I mean, its an arbitrary choice so why not follow the general convention?
  3. Once the indentation is correct, a Python program is the cleanest looking
  1. somewhat uneasy over Python indenting vs. Ruby explicit 'end'. probably a predjudice.
  2. Python requirement for explicit 'self' parameter to methods and instance variable access is very annoying
  3. Ruby OO completeness is a win over Python.
  1. Ruby blocks/lambda/yield seemed more or less equivalent (to me) to Python's named class or function. Didn't seem a big win to be able to write an anonymous function inline. In fact, one could argue that anonymous classes/functions/lambdas reduce testability because they can't be tested independently of the containing code. But on the other hand I wasn't using lambdas in the most complete sense, in which they can act on the containing environment in a way that a named function can't.

A final thought on C++. To me the C++ Standard Template Library is distinguished from the other language libraries in that it seems to be much more mathematically thought out. The containers and algorithms in the STL all have explicit runtime complexity guarantees. There seems to be much more computer science in the STL than in the other language libraries. Java is sort of like that, whereas Ruby and Python libraries seem much more ad-hoc. That probably has a lot to do with their open community driven approach to libraries. I really like how the STL was thought out and designed.


Java is more productive than C/C++. Use C/C++ only when speed or bare metal access is called for. Python/Ruby is more productive than Java and more pleasant to code in. There is a big question on static vs. dynamic typing. I contend that static typing has to be better for the purposes of program correctness, but the required cruft reduces productivity. If actual practice in large systems shows that in fact runtime typing errors don't occur often and are worth the productivity tradeoff, then I will bow to dynamic typing. I can't come up with a definitive answer to Python vs. Ruby. They seem very equivalent. Would choose based on practicality in a given situation. My general feeling was that Python annoyed me in ways that Ruby didn't, but I think those annoyances would disappear if I was using Python all the time.

Crap, the whole point was to pick Python or Ruby, but I am back where I started.


30+ Basic Linux Commands

Here are some basic Linux commands. Some are well known and some aren't. I am not a Linux
Wizard...far from it...but I am learning some basic linux commands and thought I would
share some with other newbies so they to can get more familiar with the terminal command
line. These work on my Mandrake 8.1 system.

xkill Kills a running program
exit Exits the terminal
reboot Reboots the system
halt Shutsdown the computer
startx Starts xwindows from terminal
man man(command)shows help files
info info(command) shows help files
--help (command)--help shows help files
su Allow you to login as Super User

ls "Lists" the contents of the directory
pwd Displays "present working directory"
cd cd (name) change directory TO:(name)
mkdir mkdir (name) Makes new directory
rmdir rmdir (name) Removes directory
clear Clears the terminal window

date Displays current date and time
cal Displays a calander
uptime Displays time since last reboot
df Displays the disk usage on partitions
du Displays disk usage of directory

id Displays your identification to system
groups Displays groups of current user
ulimit -a Displays users limits
uname Displays name of machine logged into
who Displays "who" is logged on the system
w Similar to "who"

wall Sends message to all logged in users
top Displays cpu processes memory etc
ps Displays current running processes

Tools advice for C and C++ programmers ramping up on XML


Designed for C and C++ programmers who are new to XML development, this article gives an overview of tools to assemble in preparation for XML development. Tool tables outline generic XML tools like IDEs and schema designers, parsers, XSLT tools, SOAP and XML-RPC libraries, and other libraries either usable from or actually written in C and/or C++. The article includes advice for installing open-source libraries on Windows, Unix, and Linux, plus a brief glossary of key XML terms.

see more. please click the link above.


There are certain basic aspects that should be kept in mind; such as the format of the code, indentation, comments, smart variables etc..
As for the basic layout, here is a tip:

1> Documentation:
This should contain the objective of the program, the creator's name and date if neccessary and other details about the program. It should be in the form of a multi-line comment.
Example: /* Program to add two numbers.
created on: 22 sept-2005, by:urjit */

2>Linking of files and Inclusion:
This section should be used to link to all header files, external files and the library functions. Macros could also be placed in this section.
Example: #include
define PI 3.14

3>Main program:
This section should ideally contain the classes (in case of C++), global variables, filestreams, and the body of the main( ) function, containing all the sub-functions, local variables, objects etc..

4>Functions and extra comments:
This section should contain the extra information and notes about debugging if required (untill the code is perfected), other functions that are to be used in the main program (for defining the functions here, they have to be declared above their control entry; i.e., generally above main).