Yes - this was the result of a whiteboarding session on the ToC.

The reason it was dropped into the page you found it was to support an ad-hoc conference call followup this afternoon whilst I was at work

Nb, at the weekend it was done without reference to any other sources and has a rationale which I presented and was hoping to flesh out a little more with others (inc Daniel).

It's not really a proposal at this point; more a strawman.

Agreed - we did not consider this at the time.

This was mentioned quite a bit in discussion but again, I agree it is not clear at all in the ToC.

The rationale here is that the guides cover the high level APIs first and only then dip down to provide reference information for material where Nokia is authoritative and deltas where Nokia has modified upstream systems.

Yes, the idea of linking out to Qt was emphasised - and Qt was identified as an example of best-of-breed.

OK - so not being aware of this at the weekend we couldn't include it.

OK, will review and comment

The idea was to do something 'unconstrained' to see what useful things came out and then to merge that into previously developed ideas so this thread can start that (although a little earlier than anticipated)


One thing that we did provide was a separation between 'setup' and 'coding'.

Setup is the first part and covers the none-code-cutting flow from sdk (or whatever) installation through various resources including mechanics of our compile/build and maemo packaging (acknowledging that windows devs will find this v. new).
Then on to the delivery options (consider how in windows you download Oracle from Oracle.com and yet in our world we get MySQL from fedora.org or debian.org) so we use Ovi and Maemo Extras for this.
I also wanted this to introduce test (and debug?) tools and community QA processes.
Finally to provide additional reading (UI/UX etc) and reference info or links (somewhat embarrassingly we forgot this during the weekend )

The 2nd part was loosely based on the platform SW architecture (which we don't have yet so it was hard to use as a basis so I stuck with random examples).

The key messages here were:
* Present the API the dev will hit first, first (eg Qt); then move on to lower levels.
* Document the APIs
* Provide "best practice" guidance (for a concrete example of the mitigated risks here see the FM radio / microphone issue which I *think* would have been avoided although it's an extreme case)
* Provide sample code for everything (nb, unit testing code could possibly be re-used if you thought about it early enough)

OK, last thing we(I) wanted to see was a consolidation application:
When you get within 200m of a friends house a sound or video would play and you'd send them an SMS or start a VOIP call depending on whether you tilted the phone left or right... or something

The point clearly is to have a useless but runnable application that shows *integration* of many of the platform capabilities.

HTH