I’m increasingly looking forward to the unveiling of lots of secrets about Symbian software. The more I hear about specific ideas third party developers have for add-on and plug-in software for Symbian devices, the more I realise that their needs will be better served once the Symbian secrecy kimono is swept away.
Take one example, from my browsing of the Forum Nokia Developer Community Discussion Board. User “jas76” asks a question:
Hi, I need to mute downlink audio (i.e. from remote end) during call; and play music on music player. Remote voice is currently mixed with music and couldn’t find a way around it with any public API/SDK plugin. All discussion thread finaly result in to microphone mute. (mute mic is possible though via SDK plugin)
Is this possible from any private API that we could request? or there is no API that could achieve it? Any experince from Nokia partners in this area?
Less than 90 minutes later, there’s an answer on the Forum, from one of the Forum Nokia Experts, “symbianyucca”:
I’m rather sure there are not such an API available.
Needless to say, jas76 had been hoping for a different kind of answer. He followed up:
Hi Symbianyucca, Thanks for your inputs. So disappointing that such a simple functionality/requirement and Nokia made it not difficult but impossible. If this is because of security reason they could lock it under some capability. But making it impossible is really really disappointing.
Thanks anyways for your response. Anyone else tried to get API from Nokia for this purpose?
And the thread goes cold.
Is the answer on the Forum correct? Is the particular aspiration of the third party developer one that is reasonable, from a technical point of view? The point is, it’s really hard to tell, without gaining access to information that is currently not available to the majority of participants of this kind of forum.
By the way, before going further, I must say that I am impressed by the helpfulness, knowledge, friendliness, diligence, and upbeat humour shown on these forums by the Forum Nokia champions – who are generally providing answers on a voluntary (unpaid) basis. These individuals do a fine job, oiling the wheels of discussion, and making lots of useful suggestions, to nurture and expand a spirit of community self-help. However, there are often limits on the help that can be provided in this way. That’s because of current restrictions on distributing the source code of Symbian OS and S60. Without access to this source code, many discussions become stalled.
Take another example. Significant numbers of developers (including researchers at universities) are keen to explore the interesting possibilities of the information known to the phone about its location. The phone itself is usually in contact with several different cell towers. If applications could access this full set of information, it would allow them to determine the position of the phone more accurately than is possible by just using information from a single cell tower. However, I’m told that no APIs are available that provide this richer set of information. On the other hand, internal Nokia applications do seem to be able to benefit from this information. (Note: I understand that this information will be available to third parties in Symbian OS v9.5 – but that’s of little comfort to developers who are trying to develop location-aware applications on existing Symbian phones.)
That’s two examples. There are many more. I probably not have picked the best examples. I’m not sure about the details of each example, and I may got some of the details wrong. However, the general points seem clear:
- Developers will in principle benefit considerably from being able to delve into currently restricted information on Symbian and S60 APIs, once the code is placed into open source;
- This will avoid the situation where, at present, too many interesting discussion threads become stalled, and enthusiasm withers away before it has the chance to create an important innovation.
On the other hand, there are of course drawbacks to this kind of openness. There are often good reasons why internal APIs have not been publicised.
For example, as soon as they are published in official SDKs, APIs become subject to tight compatibility change control. This change control is vital, for the stability of add-on and plug-in applications that depend on these APIs. But it also restricts the freedom of internal Symbian and S60 developers to evolve and improve these APIs. Especially while APIs are at an early stage in their life, there can be compelling reasons for developers to completely change their design. So there will need to be a careful education campaign, that explains that internal APIs (and many other pieces of information which developers obtain by browsing the source code) can change without warning – and may even change between two apparently similar versions of the same phone (distinguished, perhaps, only by a minor build number)!
- For this reason, I expect that discussion forums will collect and publicise information about the ways these internal APIs change between different phones.
Secondly, some part of the code of a phone will not be made public. Like it or not, the owners of some parts of the code may decide that the code would allow leakage of knowledge of commercially sensitive algorithms, data structures, or whatever. However, the good news is that, in the world of the Symbian Foundation, the extent of this kind of withheld code will be very much less than at present. Whereas the current bias often seems to be, “in case of any doubt, withhold”, the new bias will be, “release the code, unless there’s a very strong specific reason not to do so”.
So we can look forward to moving from a situation where developers are often constrained by lack of information, towards one in which the primary constraint will be their own ability. That’s a much better situation.
That leaves the question: how long will we need to wait? Given that it may take up to two years (from the initial SyFo announcement on 24th June) for the completion of the exercise to move Symbian platform code into open source, it may seem this is a far-off future vision. But many things will be happening before the end of that two year period. Parts of the source code will be released, in a staged manner, at various phases during 2009. We’ll be moving as fast as we can, subject to due care and attention – and subject to continuing to meet our very important “business as usual” commitments of interim deliveries of technologies and customer support.
dw2 