Skip to content

Doctorate Plans …

February 17, 2017

Starting PhD in Android Behavior Verification. Will publish a Poster soon.

A Website Project for a Change …

February 17, 2017

It was nice to develop for Center of Public Policy and Research. Got up to date with WordPress plugins.

Interesting Research Problem for Sensor Networks and Smart Spaces

August 13, 2011

Sensor technology in combination with pervasive computation and communication can significantly contribute to improvements in our way of living. Devising (decentralized) solutions for the construction and deployment of large-scale wireless (sensor) systems requires concentration on the application of geospatial social networking which id used for monitoring and managing crowds of people, with the aim of maintaining safety and comfort for the individuals. The central research question is how to devise a large-scale collaborative network of highly mobile, miniature, wireless devices collecting, disseminating, aggregating, and processing information to provide instant feedback to its users for the purpose of maintaining their safety and comfort.

The goal is to achieve significant progress in scaling up solutions for the deployment of wireless distributed sensor/actuator systems. These systems consist of a large collection of sensor/actuator devices that need to be shared by high-level applications. The intention is to close the gap between the networks and the applications. Some aspects of this gap are ease of installation, (self-)configuration and maintenance; ease of application development and deployment, hiding complexities of the network; and harnessing the behavior of a large network of relatively primitive nodes (constraining the emergent behavior).

This would require a cross disciplinary research effort in the following areas:

  • Technical research on wireless (sensor) networking
  • Research on geospatial social network data gathering and analysis
  • Research on human-systems interaction (including management of privacy aspects)
An edited extract from

Software Frameworks

June 4, 2011


Definition: “A framework is mainly a product for developers used as an integrated development environment that facilitates, supports, guides, confines, and helps the developers in building application in a well defined domain.” Shai Ben-Yehuda.

A Framework is a package of software libraries that abstracts computer software by wrapping them in a well-defined and reusable application programming interface (API). In other words low level API are abstracted with high level API so that programmers comfortably deal with integrated and managed low level features without understanding their peculiarities and still keeping their code standardized and correct. However, frameworks contain key distinguishing features that separate them from normal libraries.

For example, a web application framework may provide user session management, data storage, and a templating system. A desktop application framework may provide user interface functionality and widgets (common GUI elements). Almost all frameworks control at least some aspect of an application’s flow of execution.

Why Frameworks

  • Frameworks are for conceptual integrity
  • Reducing/Abstracting complexity
  • Reducing development time and effort
  • Reduce possibility of bugs and errors
  • Control the behavior for standardization


Software frameworks have these distinguishing features that separate them from libraries or normal user applications:

  1. Inversion of control – The overall program’s flow of control is not dictated by the caller, but by the framework.
  2. Default behavior – A framework has a default behavior, which must actually be some useful behavior and not a series of no-ops.
  3. Extensibility – A framework can be extended by the user usually by selective overriding or specialized by user code providing specific functionality.
  4. Non-modifiable framework code – The framework code, in general, is not allowed to be modified. Users can extend the framework, but not modify its code.


Following are some of the types of frameworks that we find in our development works:

  • Development: Eclipse. .NET, Java Development Kit, Mac’s Cocoa (AppKit and Foundation Kit)
  • Application runtime: Mac’s Cocoa Runtime, Windows Common Language Runtime, Android, Java Runtime Environment
  • Web Application: Apache-PHP
  • Security: RSBAC, GFAC, FLASK
  • Many others for specific application domain

Fundamentally, there are two kinds of frameworks:

  • A full-stack framework provides a single set of components, covering the entire spectrum of features needed to build the application. They ensure that the components work well with oneĀ another. Examples are Android, Django and Zend frameworks.
  • A glue framework provides a set of adapters and interface code. They are suppose to handle many different components at any part of the software stack. They ensure that the adapters will work well with any possible combinations of components. Examples are FLASK, GFAC, TurboGears, Twisted and Pylons.

There will always be framework developers who prefer the full-stack and there will always be framework developers who prefer glue. There will also always be developers in each camp. There will always be frameworks that can either be glue or full stack depending on the need.

There is no perfect framework. There are only different frameworks that suit different kinds of needs.



Blink App in NesC

March 12, 2011

In this second article on TinyOS and NesC programming we will visit some of the earlier concepts that we introduced in the first article. This time we will look at them from a more technical perspective so that we can understand how the Blink application fits onto the platform that enables it. Our use case application example, Blink, is basically equivalent to the “helloWorld” application that we use to learn PC targeted languages. But in our case the mote (sensor/actuator device) does not provide a keyboard or screen! Therefore we use the LEDs to blink in a manner that we command in our program.

nesC (pronounced “NES-see”) is an extension to the C programming language designed to use the structuring concepts and execution model of TinyOS. TinyOS is an event-driven operating system designed for sensor network nodes that have very limited resources (e.g., 8K bytes of program memory, 512 bytes of RAM).

The basic concepts behind nesC are:

  • Separation of construction and composition: programs are built out of components, which are assembled (“wired”) to form whole programs. Components have internal concurrency in the form of tasks. Threads of control may pass into a component through its interfaces. These threads are rooted either in a task or a hardware interrupt.
  • Specification of component behaviour in terms of set of interfaces. Interfaces may be provided or used by components. The provided interfaces are intended to represent the functionality that the component provides to its user, the used interfaces represent the functionality the component needs to perform its job.
  • Interfaces are bidirectional: they specify a set of functions to be implemented by the interface’s provider (commands) and a set to be implemented by the interface’s user (events). This allows a single interface to represent a complex interaction between components (e.g., registration of interest in some event, followed by a callback when that event happens). This is critical because all lengthy commands in TinyOS (e.g. send packet) are non-blocking; their completion is signaled through an event (send done). By specifying interfaces, a component cannot call the send command unless it provides an implementation of the sendDone event.Typically commands call downwards, i.e., from application components to those closer to the hardware, while events call upwards. Certain primitive events are bound to hardware interrupts.
  • Components are statically linked to each other via their interfaces. This increases runtime efficiency, encourages rubust design, and allows for better static analysis of programs.
  • nesC is designed under the expectation that code will be generated by whole-program compilers. This should also allow for better code generation and analysis.

The image below shows the structure (components and their wiring) of a simple application, Blink, that blinks an LED once a second:

Following is the configuration:

 *  Copyright (c) 2000-2002 The Regents of the University  of California.
 *  and Copyright (c) 2002 Intel Corporation
 *  All rights reserved.
configuration Blink {
implementation {
  components Main, BlinkM, ClockC, LedsC;

  Main.StdControl -> BlinkM.StdControl;
  BlinkM.Clock -> ClockC;
  BlinkM.Leds -> LedsC;

Following is module:

 *  Copyright (c) 2000-2002 The Regents of the University  of California.
 *  and Copyright (c) 2002 Intel Corporation
 *  All rights reserved.
 * Implementation for Blink application.  Toggle the red LED when the
 * clock fires.
module BlinkM {
  provides interface StdControl;
  uses interface Clock;
  uses interface Leds;
implementation {
  bool state; /* the state of the red LED (on or off)   */

  /* Initialize the component.
   * @return Always returns SUCCESS */
  command result_t StdControl.init() {
    state = FALSE;
    call Leds.init();
    return SUCCESS;

  /* Start things up.  This just sets the rate for the clock component.
   * @return Always returns SUCCESS */
  command result_t StdControl.start() {
    return call Clock.setRate(TOS_I1PS, TOS_S1PS);

  /* Halt execution of the application.
   * This just disables the clock component.
   * @return Always returns SUCCESS */
  command result_t StdControl.stop() {
    return call Clock.setRate(TOS_I0PS, TOS_S0PS);

  /* Toggle the red LED in response to the event.
   * @return Always returns SUCCESS */
  event result_t {
    state = !state;
    if (state) {
      call Leds.redOn();
    } else {
      call Leds.redOff();

    return SUCCESS;


Basics of TinyOS and NesC

March 11, 2011

TinyOS is an operating system for low power embedded devices, especially wireless sensor devices. It is open source with a strong developer community. Specifically it is a system, runtime environment, for nesC programs running on Mote hardware. Its features include:

  • Resource management.
  • Selected components are linked into program at compile time.
  • Written in nesC and C.
  • All time-consuming commands are non-blocking.

Some salient components are:

  • Analogue to digital conversion
  • Cryptography
  • Data logging
  • File system
  • I2C communication
  • LED control
  • Memory allocation
  • Random number generation
  • Routing
  • Sensor board input
  • Serial communication (wired and wireless)
  • Timers
  • Watchdog timer

Programming TinyOS with NesC

NesC is a dialect of C with the basic unit of code being a component. Components connect via interfaces and the process is known as wiring.

Components and Interfaces

A nesC application consists of one or more components assembled, or wired, to form an application executable. Components define two scopes: one for their specification which contains the names of their interfaces, and a second scope for their implementation. A component provides and uses interfaces. The provided interfaces are intended to represent the functionality that the component provides to its user in its specification; the used interfaces represent the functionality the component needs to perform its job in its implementation.

Interfaces are bidirectional: they specify a set of commands, which are functions to be implemented by the interface’s provider, and a set of events, which are functions to be implemented by the interface’s user. For a component to call the commands in an interface, it must implement the events of that interface. A single component may use or provide multiple interfaces and multiple instances of the same interface.

The set of interfaces which a component provides together with the set of interfaces that a component uses is considered that component’s signature.

Modules and Configurations

There are two types of components in nesC: modules and configurations. Modules provide the implementations of one or more interfaces. Configurations are used to assemble other components together, connecting interfaces used by components to interfaces provided by others. Every nesC application is described by a top-level configuration that wires together the components inside.

We will continue by looking at some simple examples in the next article.

Parse, Traverse and Search XML Docs

October 24, 2010

In this series of articles you will learn XML processing with SAX and DOM. We will make sure that the practical examples are simple yet they give you the right amount of details to dive into professional development. It will be easier to get your hands on available training source code. I am not going to use any other example based on this source code in my following web services’ tutorials. The web service example code uses obsolete libraries. The code can be used for other good purposes based on standard Python libraries.

I assume that you are already familiar with Python interpreter, packages and modules and have some fluency with the language and syntax. I also assume that you have good understanding of data structures and you have used them in programming tasks.

Parsing XML

Parsing an XML document is very simple. We use the “binary.xml” from the given example source code to demonstrate this.

>>> from xml.dom import minidom
>>> binaryxml = minidom.parse('~/diveintopython/py/kgp/binary.xml')
>>> binaryxml
<xml.dom.minidom.Document instance at 0xb777c38c>
>>> print binaryxml.toxml()
<?xml version="1.0" ?>
<ref id="bit">
<ref id="byte">
  <p><xref id="bit"/><xref id="bit"/><xref id="bit"/><xref id="bit"/>\
<xref id="bit"/><xref id="bit"/><xref id="bit"/><xref id="bit"/></p>

First we have imported minidom module from xml.dom package. minidom.parse takes one argument and returns a parsed representation of the XML document.

The object returned from minidom.parse is a Document object. It is a descendant of the Node class. This Document object is the root level of a complex tree like structure of interlocking Python objects that completely represents the XML document you passed to minidom.parse.

toxml is a method of the Node class (and is therefore available on the Document object you got from minidom.parse. toxml prints out the XML that this Node represents. For the Document node, this prints out the entire XML document.


To understand traversal and nodes try the following example code.

>>> binaryxml.childNodes
[<xml.dom.minidom.DocumentType instance at 0xb777c68c>, <DOM Element: grammar at 0xb777c6ec>]
>>> binaryxml.childNodes[0]
<xml.dom.minidom.DocumentType instance at 0xb777c68c>
>>> binaryxml.firstChild
<xml.dom.minidom.DocumentType instance at 0xb777c68c>

Every Node has a childNodes attribute, which is a list of the Node objects. A Document always has only one child node, the root element of the XML document (in this case, the grammar element). To get the first, and in this case last as well, child node, just use regular list syntax. Remember, there is nothing special going on here; this is just a regular Python list of regular Python objects. Getting the first child node of a node is a common activity. The Node class has a firstChild attribute, which is synonymous with childNodes[0]. (There is also a lastChild attribute, which is synonymous with childNodes[-1].)

>>> grammarElement = xmldoc.firstChild
>>> print grammarElement.toxml()
<ref id="bit">
<ref id="byte">
  <p><xref id="bit"/><xref id="bit"/><xref id="bit"/><xref id="bit"/>\
<xref id="bit"/><xref id="bit"/><xref id="bit"/><xref id="bit"/></p>

The toxml method is defined in the Node class therefore it is available to any (XML) node and not just the Document element.

>>> grammarElement.childNodes
[<DOM Text node "\n">, <DOM Element: ref at 17533332>, \
<DOM Text node "\n">, <DOM Element: ref at 17549660>, <DOM Text node "\n">]
>>> print grammarElement.firstChild.toxml()
>>> print grammarElement.childNodes[1].toxml()
<ref id="bit">
>>> print grammarElement.childNodes[3].toxml()
<ref id="byte">
  <p><xref id="bit"/><xref id="bit"/><xref id="bit"/><xref id="bit"/>
<xref id="bit"/><xref id="bit"/><xref id="bit"/><xref id="bit"/></p>
>>> print grammarElement.lastChild.toxml()

The XML in binary.xml seems to have two elements/nodes in grammar the two ref elements. But you’re missing something! The carriage returns … After the '<grammar>' and before the first '<ref>' there is a carriage return and this counts as a child node of the grammar element. Similarly there is a carriage return after each '</ref>'. These count as child nodes. Therefore grammar.childNodes has actually a list of 5 objects: 3 Text objects and 2 Element objects.

The first child is a Text object representing the carriage return after the '<grammar>' tag and before the first '<ref>' tag. The second child is an Element object representing the first ref element. The fourth child is an Element object representing the second ref element. The last child is a Text object representing the carriage return after the '</ref>' end tag and before the '</grammar>' end tag.

>>> grammarElement
<DOM Element: grammar at 19167148>
>>> refElement = grammarElement.childNodes[1]
>>> refElement
<DOM Element: ref at 17987740>
>>> refElement.childNodes
[<DOM Text node "\n">, <DOM Text node "  ">, <DOM Element: p at 19315844>, \
<DOM Text node "\n">, <DOM Text node "  ">, \
<DOM Element: p at 19462036>, <DOM Text node "\n">]
>>> pElement = refElement.childNodes[2]
>>> pElement
<DOM Element: p at 19315844>
>>> print pElement.toxml()
>>> pElement.firstChild
<DOM Text node "0">

As you saw in the previous example, the first ref element is grammarNode.childNodes[1], since childNodes[0] is a Text node for the carriage return. The ref element has its own set of child nodes, one for the carriage return, a separate one for the spaces, one for the p element, and so forth. You can even use the toxml method here, deeply nested within the document. The p element has only one child node (you can’t tell that from this example, but look at pNode.childNodes if you don’t believe me), and it is a Text node for the single character '0'. The .data attribute of a Text node gives you the actual string that the text node represents. But what is that 'u' in front of the string?

The 'u' means that the string has unicode encoding unlike the default ASCII in Python environment. The reason is that web services standardize encoding with unicode and that is the same reason why 'u' precedesĀ  '0'.

Searching for elements

Traversing XML documents by stepping through each node can be tedious. If you want to find and get to an element in a hige XML document then there is a smart way to do it. getElementsByTagName.

>>> from xml.dom import minidom
>>> binaryxml = minidom.parse('binary.xml')
>>> refList = binaryxml.getElementsByTagName('ref')
>>> refList
[<DOM Element: ref at 136138108>, <DOM Element: ref at 136144292>]
>>> print refList[0].toxml()
<ref id="bit">
>>> print refList[1].toxml()
<ref id="byte">
  <p><xref id="bit"/><xref id="bit"/><xref id="bit"/><xref id="bit"/>\
<xref id="bit"/><xref id="bit"/><xref id="bit"/><xref id="bit"/></p>

getElementsByTagName takes one argument, the name of the element you wish to find. It returns a list of Element objects corresponding to the XML elements that have that name. In this case you have two ref elements.

>>> firstRef = refList[0]
>>> print firstRef.toxml()
<ref id="bit">

The first object in your refList is the 'bit' ref element. You can use the same getElementsByTagName method on this Element to find all the <p> elements within the 'bit' ref element. The getElementsByTagName method returns a list of all the elements it found (in this case 2).

>>> pList = firstRef.getElementsByTagName("p")
>>> pList
[<DOM Element: p at 136140116>, <DOM Element: p at 136142172>]
>>> print pList[0].toxml()
>>> print pList[1].toxml()
<p>1</p>>>> pList = xmldoc.getElementsByTagName("p")
>>> pList
[<DOM Element: p at 136140116>, <DOM Element: p at 136142172>, <DOM Element: p at 136146124>]
>>> pList[0].toxml()
>>> pList[1].toxml()
>>> pList[2].toxml()
'<p><xref id="bit"/><xref id="bit"/><xref id="bit"/><xref id="bit"/>\
<xref id="bit"/><xref id="bit"/><xref id="bit"/><xref id="bit"/></p>'

Note carefully that the difference between this and the previous example. Previously, you were searching for p elements within firstRef, but here you are searching for p elements within binaryxml, the root-level object that represents the entire XML document. This does find the p elements nested within the ref elements within the root grammar element. The first two p elements are within the first ref (the ‘bit’ ref). The last p element is the one within the second ref (the ‘byte’ ref).

This article reduces theory and provides more focus on techniques by example. This tutorial has been derived from Dive into Python, Chapter 9.