You Are Here:

Community: Blogs

Paul Todd's Forum Nokia Blog

Symbian signed and openess

Paul.Todd | 08 July, 2008 12:11

I hav'nt posted for a while, primarily becuase I am behind in whitepaper writing and partially due to work commitments.

Anyway I am working on a new set of posts explaining the OMA-DM adapters and how to access them so this will be starting in a few days as I have realized the existing documentation for this is woefully inadequate for something so powerful.

However, onto the cheese as people say... David Woods has an excellent article on Symbian Signed over at his blog

 However there  are some fundemental issues I disgree with.

1. As he was part of the Symbian Signed  design team he knows it inside and out. Most developers do not know or understand the nuances of capabilities and how they apply to which dll is loaded with what capabilities and it even goes as far as signing a sis file. Even the documentation is far from clear. One only needs to look a the rule for dynmically loading a dll vs statically loading a dll. Whilst David may know it as he designed Symbian, a Windows or j2me developer will not.
In the past I have had  more than my fair share of problems explaining to other dev's why it is a bad idea to run services with the TCB priviledge on Windows and its orders of magnitude more complex to explain capabilities on Symbian.

2. how the hell can someone rewrite an OS and forget to document which API's have have what capabilities. Enough said really (whilst ROFL)

2.1 How can someone rewrite an OS and forget to put in decent logging and helpful error messages when an application fails to run or install (still ROFL'ing)

3. Getting decerts for other competing products is a piece of cake compared to Symbian. MS, RIM and Apple are simple and it just works.(Not ROFL anymore)

4. If anything I see device manufacturers using capabiltiies to prevent people distributing applications that can compete with other solutions or preferred suppliers. Lets say I write an antivirus application with the new Symbian Foundation API's, I am still beholden to the device manufacturer to grant the capabiltities to install and run my product.No where does it say Symbian Signed will be the point at which an application will be rejected for quality concerns. The way I see this playing out is that manufacturer will still stop developers getting devcerts with all capabilities (eg TCB) under the guise that they only work with "partners" and not with ISV's so developing for example an antivirus solution will never happen because of manufacturer lockout. Whereas Symbian Signed should be the gatekeeper for applications to be run on the phone it is much more likely that capabilties will still be the paper work nightmare they currently are.

For these issues, I unfortunatly I still see Symbian Signed as a revenue black hole for ISV's in the moribund ISV app market.

So enough with the "open source" washing PR and more with concrete support for developers because ultimately we are the people going to deliver the applications that sell the phones and lets make sure they are Symbian and not Android or Limo phones.

 If you really want to impress me, say that the Symbian Foundation and Nokia are adopting the principals and practises of Maemo and not Microsoft.

 
 

Rate This

 
 
Bookmark this page: DeliciousDiggFacebookGoogleYahooStumbleUponRedditDiigoTechnocratiTwitter  Share this page Share this page Print this Page Print this page Invite a friend Invite a friend
京ICP备05048969号    Email Newsletters Press Terms & Conditions Privacy Policy Sitemap Contact Us © 2009 Nokia 
RDF Facets: qdcZidentifierQSxhttpE3aE2fE2fblogsE2eforumE2enokiaE2ecomE2fblogE2fpaulE2dcoultonsE2dforumE2dnokiaE2dblogE2farchivesE2f2009E2f04E2fX qdcZtypeQUqfnZE45E78cludedFromGeneralE4cistingsQ qdcZtypeQUqfntypeZBlogContentQ qdcZtypeQUqfntypeZCommunityContentQ qdcZtypeQUqfntypeZE52esourceQ qdcZtypeQUqfntypeZWebpageQ qdcZtypeQUqmarsZManagedE52esourceQ qdcZtypeQUqwebZInformationE52esourceQ qdcZtypeQUqwebZPageQ qdcZtypeQUqwebZE52esourceQ qdcZtypeQUqrdfsZE52esourceQ qfnZtypeQUqfntypeZBlogContentQ qfnZtypeQUqfntypeZCommunityContentQ qfnZtypeQUqfntypeZE52esourceQ qfnZtypeQUqfntypeZWebpageQ qmarsZlanguageQUxhttpE3aE2fE2fswE2enokiaE2ecomE2flanguageE2d1E2fenX qrdfZtypeQUqfnZE45E78cludedFromGeneralE4cistingsQ qrdfZtypeQUqfntypeZBlogContentQ qrdfZtypeQUqfntypeZCommunityContentQ qrdfZtypeQUqfntypeZE52esourceQ qrdfZtypeQUqfntypeZWebpageQ qrdfZtypeQUqmarsZManagedE52esourceQ qrdfZtypeQUqwebZInformationE52esourceQ qrdfZtypeQUqwebZPageQ qrdfZtypeQUqwebZE52esourceQ qrdfZtypeQUqrdfsZE52esourceQ