Mark Wilcox's Forum Nokia Blog

The way I see it, sooner or later [almost] every system is bound to follow the course of this 4-step "road to perdition".

Maybe at first you weren't experienced enough to write the code immaculately... maybe you were under pressure to release the product to meet a deadline... maybe some other circumstances prevented you from making the project at least decent... Whatever the case, the deed is done and in most cases simply patching it here and there won't solve the problem.

S60 started out as a great smartphone platform. At least for me it was (and in many aspects it still is). I really had the feeling of openness even just from being able to install additional software. Then, like you said, things started to go awry. The attempts to boost platform security, though well-intended, have hindered the projects of 3rd party Symbian software developers, thus taking away some of that openness.

As for the parallel interfaces, I agree. It's a pretty obvious, though inexact, solution. Adding new features to the new, cleaner components and slowly but surely deprecating the old, faulty ones seems the way to go. That's my opinion.

Just some thoughts I thought I'd share.

Best regards,
Bogdan

Hi!
I suppose you're quite right. :(
What's more, regarding significant delays before shipping S60v2 and S60v3: it seems the main reason for this is migrating from EKA1 to EKA2.

@Bogdan, that's a pretty pessimistic view. I hope it isn't true. Linux is at the other end of the spectrum, constantly refactoring and updating interfaces. I've seen first hand that it causes a nightmare for commercial developers on embedded platforms who have to port all of their drivers, file systems and other kernel modules on a regular basis. Hopefully there is a middle ground somewhere.

@Damavik, I don't think the EKA1 to EKA2 change really made much difference to most of S60 (although the adaptation software perhaps more so). The platform security change at the same time was rather larger and the more full implementation of scalable UI (more applications working in portrait and landscape) was also quite significant in terms of timescales I think.

Mark

Mark,

I worked on S60 RnD from the time it wasn't called S60 at all (not even Series60) until they released S60 3rd Edition SDK. I can tell you that it took ~3 years to come out with the first version of the SDK (v0.9) and it wasn't a rush at all. Everyone learned how to do Symbian development at that time and how to collaborate with one another.

Then I remember when newer versions of S60 (and Symbian OS) came out we had to keep track of parallel platforms: we learnt what variations are and how to write code that runs on newer platforms, but doesn't affect older ones. Nokia made the commitment of source AND binary compatibility, which I admit, but it also represented a burdon on us: how can you change the behavior of a module without breaking essentially anything in dependent modules?

From compatibility point of view, it was a fresh air we could breath when we heard that during the course of migrating code from S60 2.x to 3.x we could also break our APIs. ANY APIs could be broken, it was time for renovation. Of course, you had to have very good excuse to break an SDK API, for example, but you could do it. For example, even CommDb API got broken and replaced by CommsDat. How did Symbian do it? They provided a shim layer that had the same API as CommDb, but used CommsDat underneath. That shim layer was made available (and still is?) to licensees, such as Nokia, throughout several minor version (v9.x).

Finally, my personal opinion: I admire Symbian & Nokia to be so strong that they committed themselves to maintain backward compatibility. I think the way Linux follows is very bad for ISVs and doubt that it's good even for platform developers. On the other hand, I agree with you that maintaining backward-compatibility leads to slower, less efficient, uglier, etc. code in the long run. My suggestion is why not have a facelift from time to time? The introduction of Platform Security gave the opportunity to revamp code that had to be revamped. I think the introduction of Touch UI should not cause any storm similar to that. As S60 backward-compatibility was promised with the new Symbian Foundation codebase, too, we shouldn't expect major breaks in that code, too. However, it'll be time for another revamp after that.

Hi Tote,

Thanks for your long reply. Actually I think ~3 years was pretty fast for the development of a complete phone platform on a new (to most of the people working on it) OS in a different language than they were used to (C++ vs C). I'm sure it wasn't rushed, that isn't the Nokia way! I also think everyone did a good job. There was no way to know at that time what the platform would become.

As you say, guaranteeing backward compatibility is a burden on the developers and possibly a necessary one. Perhaps the shim layer solution is a good one - only you don't have to include the shim in the firmware, you could release it as a library that third parties can include with their releases until they have migrated.

Just my opinion but I think that while maintaining binary compatibility is great for developers in the short term, in the long run it's bad for everyone as the system becomes unmanageable and the code multiplies. If you look at the expanding size of S60 deliveries over time compared to the functionality added you can see what I mean.

However, someone very senior (can't remember exactly who said it now) has stood up in public and promisied binary compatibility forever! So we'll have to wait for memories to fade for quite a while before the next major revamp. That's why I expect parallel interfaces. It's a good job flash is cheap now!

Mark

P.S. I agree the Linux situation is worse and wouldn't want to go that way. Kernel developers change things whenever they want - there doesn't have to be a good reason to break source compatibility, and of course binary compatibility just doesn't exist at all on Linux.

To me it seems the two biggest problems with under-engineering in S60 are in API design and documentation. The API was broken from the start, because they chose to base it on the Symbian UI framework. It shows that the people involved didn't have much experience with good UI toolkits. Both Qt and GTK+ were being developed at about the same time, and they're both sane UI toolkits. Epoc32 itself was developed by people with virtually experience in object oriented development, which shows everywhere in the system. (See The Symbian OS Architecture Sourcebook for references.)

As for the documentation, this is something that is often neglected, because the deadline is approaching and you have to fix critical bugs instead of writing documentation. Especially the UI resource documentation has gone completely undocumented for many years. I haven't really followed what's been going on with 3rd ed. FP1 and FP2, so maybe it's improved now, but you shouldn't have to wait for 5 years for core API:s to be documented at all.

The documentation problem is quite easy to fix, given enough resources. The API problem is very hard to do something about, and with the acquisition of Qt, it looks like Nokia have realized this, and are preparing to replace the UI layer.

Yes, for many years the SDK documentation on S60 components has been almost non-existent rather than simply under-engineered. It isn't a lot better now. Oddly a lot of effort seems to have gone into producing pretty PDFs and screencasts for how to do stuff but the core issue of undocumented APIs in the SDK docs remains.

I think there was plenty of object oriented design experience at Symbian, it's just that a lot of the frameworks have designs that made a lot of compromises for extremely resource constrained environments that simply don't exist today.