Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Qualcomm's Gimbal context awareness SDK



Stephen Ronan wrote:
> Perhaps relevant to future functionality where Apple may or may not play
> a leadership role:
> http://scobleizer.com/2012/07/11/mobile-3-0-arrives-how-qualcom-just-showed-us-the-future-of-the-cell-phone-and-why-iphone-sucks-for-this-new-contextual-age/

The gist of this is that a phone using Qualcomm chips and implementing
the Gimbal context awareness SDK will be able to suggest things to you
based on where you are and what's around you.

While the potential to accomplish this is ever increasing with more
powerful, more connected phones loaded with sensors, it's never going to
be the idealized version depicted in the video. A real person's life is
fragmented across many devices, some of which won't allow the capturing
of data. For example, you order your pizza using an old-style land line
phone. Neither your cell phone nor Facebook is aware of that expressed
preference.

Not to mention that Qualcomm is claiming that all this will be happening
inside the phone. Does that mean it wont be pulling data from Facebook
and other online sources of your preferences? Seems contradictory.

Sure, this contextual stuff will happen, but its akin to speech
recognition. We went though hundreds of cycles of thinking is was just
around the corner, yet there never was a distinct inflection point like
Scoble seems to be predicting for this context technology, where it was
orders of magnitude better. It just slowly, progressively got better.


  Roland Ligtenberg, product developer at Qualcomm Labs...told me that
  if you did all this in hardware there would be a lot less battery
  cost.

This is guaranteed to be a vague and inaccurate statement. You *can't*
do all this in hardware, unless you build an insane amount of hardware.
You can offload pieces of the problem to hardware, like having a super
low power, slow microcontroller monitoring the GPS to see when the phone
arrives in one of the "geofenced" contexts and then wake up the big CPU,
but you're still using a ton of software.


  Which brings me to why Apple sucks.

  Apple does NOT give developers access to the Bluetooth and Wifi
  radios. This is going to really hinder developers in this new
  contextual world.

Nice to see Scoble stepping out of Apple fanboy mode. I get the
impression, though, that this blog posting is half intended just to be a
way to goad Apple into providing an API.

The reality is that if this takes off, Apple will provide an API to
their app developers for accessing the radios. If it is functionality
Apple wants, or functionality that market pressure makes Apple want,
then it'll be supported.

The danger in choosing a more closed platform is not that you wont see
support for functionality that's heading towards mainstream, but that
you'll never have the ability to do the "long tail" things that just
never rise to Apple's attention.

Scoble really has no business being annoyed with Apple, as this is just
the other side of the coin he praises so often.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org