OQO SDK + OQO Software Developer Forum

[Guest]

[PlacidoDomenech]

When OQO company give us a OQO SDK supporting OQO 01, 02 , and 03 future model?

I think is very important for the developer community that do LOB applications, with mobile solutions with OQO hardware.

Why not open a OQO Software Developer Forum, too? :

I think the OQO must have unique app-killer software and hardware, to differ from the competition (MID, Asus EEEPC, UMPC, notebooks, tabletpcs, iPhone, etc.)

What do you think, guys?

Thanks

[Stuart]

I completely agree.   I've had email with OQO on this subject and the answer was a simple "No".  I aslo asked if they could just supply documentation.

[stuartguthrie]

Yeah, I completely agree. I think it's a great idea! It appears as though the OQO user database has a lot of talented developers out there so why not put the talent to use and create OQO specific solutions and software.

BTW what does LOB stand for?

Stu

[PlacidoDomenech]

LOB is line of business applications. ERPs, mobile solutions, CRM,etc. Is that your question Stuart?

[Stuart]

I'll add that if it's a resource issue at OQO, an unsupported SDK or docs would be fine.  I'm sure we can be self supporting here.

[Picasso]

What do you want access to via an SDK that you can get via windows now?

[Stuart]

I already answered this question for you in another post. 

Touch Scrollers (raw, not a mouse actions)
Light Sensor
Keyboard exposed/closed
Wireless and Bluetooth radio control

I'm making input enhancements that auto enable/disable/configure based on these "inputs".  So far, I've only been able to do the touch scroller, but I only have relative position and not absolute which makes it less than optimum.

[PlacidoDomenech]

Practically the same as Stuart:

-Enable/disable wifi
-Enable/disable bluetooth
-Enable/disable 3G
-touchscrollers
-Rotate (this is already available in internet but not oficial by OQO)
-Light sensor.
-Keyboard open/closed

In the future OQO 03 GPS, phone functionality, digital camera, web camera, biometric finger security, etc. 

But for example what about guides for oqo development:

-Key Practices for OQO Application Development.
-WPF Performance considerations.
-SQL Server 2008 configuration and optimization.
-.net Framework 3.5 deploy considerations.
-Vista configuration and optimization for ISV Vertical solutions.
etc.

As software company we bring the necessary help for the community, because we are immersed in the development of software in these technologies.

I like this type of support from OQO directly or in help with the community.

What do you think?

[stuartguthrie]

LOB is line of business applications. ERPs, mobile solutions, CRM,etc. Is that your question Stuart?

Thanks for the definitions. I did do a search for LOB but it came up with a lot of results and I didn't quite know which one you were referring to.

Thanks,
Stu

[JCC]

I think exposing APIs is a great idea for us, the end user. It lets us develop software which takes advantage of OQO specific features. (I do wonder about the maximum practical sample rate of the accelerometer.)

However, it's additional work for OQO to put their material together in a complete and coherent fashion. (I mean, they won't be shipping an OQO employee with each copy.) Also, this would lock them into the API they currently have. Right now, they have a lot of flexibility because they are the only developers using their interfaces. If they change the API, they can change all the programs that use them at the same time, then have OQO users update both in at once. They lose this the instant the publish the API. So, the first thing they'd have to do is make sure they're happy with what they have because it will be hard to change later.

It may spur development of OQO specific software, but will it spur enough development for it to be worth their trouble? I have no clue.

[Stuart]

One could argue that DOS through Vista is the longest and biggest backward compatibility API story, but even with that, driver models and APIs changed enough at each major release that they often required updates to 3rd party drivers and hardware specific applications.

OQO so far (granted a small sample of two) has follwed the cell phone model.  You get the device, there might be a bug fix or two, but significant new software features don't happen.

So I don't think it's unreasonable for OQO to say that here are the details, but it only applies to model X, use as-is.  Since they're likely to mkae more than bug fixes, I don't think "locking them in" is a problem either.  I for one, would be fine with having to rerelease the app for each device (at least for the next several years at one model every couple of years).  Since each device is likely to have a different special hardware set, I'll be making changes for the next model anyway.

IMO, it will spur more development and sales than it will "cost" OQO.

[JCC]

One could argue that DOS through Vista is the longest and biggest backward compatibility API story, but even with that, driver models and APIs changed enough at each major release that they often required updates to 3rd party drivers and hardware specific applications.

One could also argue that one of the problems slowing Vista adoption is the lack of updated drivers.

So I don't think it's unreasonable for OQO to say that here are the details, but it only applies to model X, use as-is.

Are we the same group of people who insist that the hypothetical 03 use exactly the same power connector as the 02? I hope not. [I'm not, in any case.]

In any case, there may be a difference between what you are ok with and what a company that suddenly finds themselves supporting multiple versions of their OQO specific 3rd party software may be ok with. OQO itself may not be thrilled with having to publicly support multiple versions of an API.

Also, note that the original request was for "a OQO SDK supporting OQO 01, 02 , and 03 future model." One SDK which supports all models is the default assumption, not a separate SDK for each model. You're ok with a new SDK and rewriting your program every time OQO makes a change. Other people will get caught by surprise.

Besides, it may not change just at model launch. Right now, there's nothing to stop OQO from changing things whenever they wantl. e.g., people complain that OQO Manager causes CPU spikes. If there were an API change that would make fixing this really easy, right now, they could do that. Of course, there's nothing about publishing an API that makes this impossible. But they're liable to piss more people off if it's not a backward compatible change.

[Again, I point out the work to put all this documentation out. It may simply be a manpower issue.]

I personally would love for them to expose the details of how to take advantage of OQO specific features in my software. This isn't an argument for why they shouldn't. I'm just not surprised that they haven't.

[I mean, along the same lines, I'd like for them to publish details about their specialized power connector. However, I don't ever expect them to.]

[Stuart]

OQO is not on par (size) with Microsoft and their devices are not on par (scale) with Windows.  My point was that even Microsoft doesn't have the level of compatibilty support you're suggesting OQO may need to do.  The number of developers OQO would "support" is very small, and being such a specialized and focused group it's not unreasonable or unusual at all to tell them to expect to have to make changes and recompile for each device version.  The oroginal ask for a multi-version SDK may have been too much to ask or expect.  I'm stating what I think is reasonable to expect and doable from a company this size.  If we wait for an OQO MSDN, we'll probably never see it.

Besides, it may not change just at model launch. Right now, there's nothing to stop OQO from changing things whenever they wantl. e.g., people complain that OQO Manager causes CPU spikes. If there were an API change that would make fixing this really easy, right now, they could do that. Of course, there's nothing about publishing an API that makes this impossible. But they're liable to piss more people off if it's not a backward compatible change.

My point was that they haven't made significant changes, and I would be surprised if they did.  The fact that they run an entire application (not driver) at above normal priority means they're not too worried about a CPU spike, but that's another topic.

Are we the same group of people who insist that the hypothetical 03 use exactly the same power connector as the 02? I hope not. [I'm not, in any case.]

That would be nice, but just as with their software and drivers, if they made a change for the better I wouldn't mind at all.

[PlacidoDomenech]

The software teamed with a killer hardware like OQO, the idea iphone translated so well, is we all need. Because if OQO don't do it, anoher will do. Sure. The market for mobile solutions, always connected world, with smartclients working in online and offline mode, syncing via Internet services, etc. is the future.

We have OQO hardware killer... give us basic SDK... and help developers boost OQO sales with innovative mobile solutions. We are developing one in this wave. I hope i can put some screenshoots soon...

I can't imagine new model of OQO (gps, cameras, multitouch,etc.) , without SDK, without software support, although minimal...of his hardware... not only Microsoft support.

I think can be done... with the help of community, don't you think so guys?

[JCC]

My point was that even Microsoft doesn't have the level of compatibilty support you're suggesting OQO may need to do.

Do you think I'm arguing why OQO shouldn't do this? I'd love for OQO to release an SDK.

I'm also cognizant of the sheer amount of work involved just to get an SDK out the door, much less any level of compatibility support. (Somehow, the former got lost and we focused the latter.)

You may not want compatibility. However, I suspect that there are software developers who do.

My point was that they haven't made significant changes

How do you know? If they change the drivers and the applications which use them at the same time, then they've effected an API change invisible to you. That's my point.

Like I said, if they just put out a set of documents saying, "Here's how to access OQO specific features. Any or all of this information could change without warning at any time." I personally would be fine with that. A software company who has a business interest in making sure its software runs on as many OQOs as possible may think differently.

Like it or not, OQO is not oriented towards the hobbyist who just wants to write a nifty gadget that uses the accelerometer. They're oriented toward partnering with other companies. I don't actually think this is a good thing. This is just what I see.

(Otherwise, we might have had an effort like Nokia has with Maemo by now. Note that with Maemo, when new releases required people to recompile their software, they complained. Unsurprising, really.)