P.I.P.S or P.I.P.S is POSIX on Symbian (yes, its one of those ever so trendy recursive acronyms) is the first stage in the implementation of POSIX standard libraries for Symbian OS. The implementation of these libraries will make it considerably easier for C developers to build platform independent application engines for Symbian phone or take existing projects mobile.

Richard: This first release of P.I.P.S covers four POSIX libraries: libc, libm, libpthread, and libdl. What guided the selection of these for the first release?

Erik: There were basically two reasons for choosing these libraries. Firstly they are the core, low level libraries, providing things like dynamic loading. This means they are the foundation for implementing many of the other libraries. Secondly, functions in libraries such as libc and libdl include systems calls that have to be mapped down to Symbian OS. So these libraries involve the most optimization to get them working efficiently on Symbian OS; addressing issues such as mapping of POSIX style resource handle into the Symbian style.

Richard: What other optimization challenges did you have?

Erik: Possibly the most challenging was the issue of writable static data. This is a feature of C development that has only recently become available in Symbian OS, because of its memory use implications. To gain proper compatibility P.I.P.S has writable static data support permanently on, but it does mean there is a penalty on memory usage.

Richard: Does this mean there is a danger that applications using P.I.P.S won't be a memory safe as Symbian C++ applications?

Erik: It's really a case of the right approach to the job. While Symbian C++ uses paradigms designed to ensure good performance on mobile phones -this is how the operating system, middleware and UIs are implemented to ensure they are memory efficient and secure, and the OS will continue to be created this way - now third party developer have the choice of using Symbian C++ or taking a more open route using POSIX libraries.

It will really come down to where the development effort is expended. A developer taking an existing large C project to Symbian OS using P.I.P.S won't spend most of their time coding. They will spend most of there time testing. By contrast a new project using Symbian C++ might split development and testing time 50:50. On a project using P.I.P.S much more of the development effort will be in testing, to ensure the application works in the more demanding mobile phone environment.

Richard: Given these first libraries are implementing fundamental functions, how useful will they be for the majority of existing C projects?

Erik: Definitely useful from day one. To illustrate this we are working on a porting a well known open source project and will be producing a white paper describing the process and how long it took. But the initial port of the engine took one developer just a couple of days.

I should point out that there is one aspect of development P.I.P.S does not address and that is the UI. As you know Symbian C++ applications generally employ an engine separate from the UI. This design paradigm continues with these libraries. For our example port we have discarded the original UI and created a simple Symbian based UI.

However, P.I.P.S is under development and as we add more libraries P.I.P.S will be able to cover more projects.

Richard: Long term will developers get to choose between standard C and Symbian C++ for all their application development?

Erik: No, because it won't include the UI, as Symbian does not develop UIs. Phone UIs differs considerably from standard UIs like X-Windows. There is no suitable open standard to work with, although you never know what might emerge from the likes of the Khronos Group.

Richard: What about backend APIs, accessing contacts for example, will there be a P.I.P.S C alternative for these?

Erik: For the time being developers will need to use a hybrid approach. The goal in creating P.I.P.S is to bring existing desktop software to Symbian OS. These applications don't tend to access contacts in other desktop applications. So to use Symbian OS features, like contacts, developers will need to mix and match P.I.P.S with Symbian C++ APIs.

Having said that, if there was a standard library for contacts access then we would certainly look at adding it to our roadmap, but we are not aware of one.

Richard: You mentioned the goal is to bring desktop applications to Symbian OS, how do you see this happening?

Erik: The focus is very much on open source projects. Many open source projects could easily run on Symbian phones, particularly as the processing power and onboard memory are growing.

My personal aspirations are to see open source developers bring their projects to Symbian. I hope this result in many open source projects offering ready made Symbian OS binaries, in the same way many today offer ready made binaries for Windows or Linux. It won't happen overnight but P.I.P.S provides the tools for it to happen.

Richard: Given many of these projects are designed for powerful desktop computers are they really practical for Symbian phones? Equally is desktop software right for mobile devices?

Erik: I believe so. If you look at the top 10 downloads on SourceForge many will be file sharing applications, such as eDonkey or BitTorrent. Those are eminently suitable projects for porting to Symbian OS with P.I.P.S - particularly when you consider that Symbian C++ applications have been written to implement the protocols.

I know some people question why anyone would want to run this type of application on a phone, given the costs of data traffic, but with flat rate data plans and WiFi they are becoming practical. I can see the popularity of these applications in the PC space translating to Symbian phones and with P.I.P.S it now much more achievable.

For more information on P.I.P.S will be available on http://developer.symbian.com, with the P.I.P.S downloads for Symbian OS V9.1 due to be available before the end of Q1 2007.