Introduction to Selects and Attributes

Keywords: 2.0.x | Book | core

In earlier versions of SERi, only a very limited amount of information related to the request being processed was available in the routing script. The amount of things that could be done in the script thus was rather limited. Many scenarios required the user to actually write a new module.

In SER 0.9 this situation changed somewhat with the introduction of AVPs. The original concept was to store some information for your users in a database table and load them on demand. The avpops module even allowed to manipulate the information albeit not in a very intuitional way.

For SER 2.0 the concept was spiced up a bit. AVPs are now called just attributes and are available in a more intuitive way. Even more, a new framework was introduced to allow access to all sorts of information from the request and SER's entrails. The developers decided to call it the select framework.

The key to understanding these two concepts is to know that they are actually slightly misnamed. This is especially true for selects which have nothing to do with the select construct found in some programming languages whatsoever.

In practice, you can think of attributes as variables and selects as constants in the traditional sense used in other programming languages. For both attributes and selects you can fetch their current value in your routing script for various purposes: You can compare them with literals or other selects or attributes, you can pass them to functions through parameters, etc. But you can only assign new values to attributes. The information inside a select is strictly read only.

As with almost all things interesting things in life, however, there is a bit more to the story. In order to allow access to all information in a request, selects can turn into rather long expressions with arrays and sub-selects. Attributes are even more complex. Since you may want to store and access information for both the caller and callee, there are two groups. On top of that there is a hierarchy classes that allow to have different information for domains and users.

In the following, we will have a closer look at both. We will start with selects and then proceed to attributes.

Selects

The original intent of selects was to allow access to all parts of the request currently being processed in a uniform and easy to understand way. Since then they have been made available to modules so that they can introduce their own selects. More and more modules are likely to pick this up and sooner or later a multitude of selects will be available in the average routing script. To avoid an utter mess, some structure had to be introduced.

It was borrowed from some computing languages where you can store a data structure inside another data structure inside another structure and so on. Often, if these structures are arrays they are accessed by stating the index in square brackets; if they are structs (or records), the attribute in question is introduced by a dot.

That's almost exactly what selects do. They start with an at sign (@) to tell the script parser that a select starts. Now follows a series of parts. Each part can have a name or a number. Names are separated by a dot, numbers are enclosed in square brackets. If the name contains special characters, such as spaces, it needs to be enclosed in square brackets plus quotation marks. In this case, the period is left out.

Sounds complicated? It's not. Let's say you want to access the host part of topmost Via header field. The Via headers are available through a select that starts with @via. If you just use this, you get the entire topmost Via. If you only want a component of the Via, you say which as the second part of the select expression. If you want the host, the expression thus is "@via.host".

If you want the host part of the second Via, this is possible, too. If the part after the @via is an integer, it is interpreted as if you access all the Via headers as an array. The topmost Via header has number 1, the second one has 2. Programmers beware: The array doesn't start with 0 but with 1. So, if you want the host part of the second Via header, the select expression is "@via[2].host". This pretty much is it.

Which selects are available can be found in the reference. Or it will be, once that is written.

XXX I guess a short list of the most important selects may follow.

AVPs

Home |  Recent changes |  Search |  Glossary |  Sitemap |  Login