I’m moving on to a company called Opscode.  They’re based in Seattle, though I’ll be working from my home office most of the time.   Opscode owns and maintains the open source project “Chef” – an infrastructure tool for programmatic rapid deployment and configuration of servers and environments.

And to answer the inevitable — of course BBSSH will continue on

***

I had to take a step back here. If I saw this on Ars Technica, Wired – hell, even CNet or ZDNet — I would believe it. So why do I question the veracity because I’m seeing it on BGR?

I realized that it is a matter of reputation. You can trust that when Ars Technica states a source is verified, it has been verified. The same with the others. Because they run like news organizations and not blogs. Reports are typically well researched and contain verifiable factual information. In cases where we must accept their word for it, it’s repeatedly been proven correct over time.  (Note: this applies to what’s reported in the “news” areas of these sites, and not opinion/blog.)  When information is incorrect, they publish corrections and/or retractions.

Contrast this to BGR – they’ve a middling-to-decent track record with getting the scoop on various device leaks, but beyond that they report only rumors, analyst speculation, and unverifiable ‘exclusives’ as news.  When they post something that’s later proven wrong, you’ll seldom if ever see them acknowledge this.

Given this rather well-known (in tech blog circles) lack of reputation, I have a hard time believing that a highly placed executive wishing  to write an anonymous ‘open letter’ or even send emails supporting such an open letter would actually send them here to BGR  as opposed to an actual news organization.     I am not saying it didn’t happen – only that it raises at least the shadow of a doubt.

The choice of where these purported employees sent the letters will always cause that legitimacy to be called into question. Even if they are real – and certainly the first of them raised some potentially valid points – they can never be taken quite seriously because they were first published at bgr.com as “exclusives”.

I’m not saying these letters are fake – I really don’t know if they are.  But then – that’s my point.  I don’t know, and BGR doesn’t have the proven track record that will let me trust their assertion.  They haven’t earned the credibility required.

A common problem to be addressed with both is packaging the app in such a way that it will launch properly with a UI – but I’ve not yet gotten that far.

Option 1 -  a hybrid interface, using AIR to provide the UI and rendering only,  and a custom C library to manage terminal(s)  states, handle connections, etc.   This was the most appealing, because it’s relatively simple to make UIs in AIR; and the actual painting logic for a terminal is pretty straightforward.  State management (eg terminal emulation) is a lot more complex, and not something I really wanted to write in ActionScript.

Option 2- a “pure native” interface.  Since RIM has announced that there is no UI capability in the native toolkit, this means I’d need to use OpenGL to handle UI and rendering.

Both of these would be backed by a custom library to handle terminal state, telnet connectivity, libssh, etc.  This architecture will also make it trivial to provide additional services – such as running a local shell on the PB through the app, or using BBSSH bridged via bluetooth; similar in principle to the bridged BB apps we already have, this would let your connections, keys, etc remain on the BB while the PB app just does the rendering.

Unfortunately, I’ve run into a dead-end for Option 1.  I was looking at AIR native extensions as the best means of integrating native code and AIR UI.   Initially, it was promising – the AIR native extension capability is exactly what I need to do what I plan for BBSSH.  I ran into two problems according to the documentation: in order to build, I would need a prewritten C++ source file that is included with AIR’s proprietary EDK.  I have not been able to get this from any source.

Perhaps as importantly, the documentation states that the AIR for TV profile (that’s what is apparently on the BB) does not allow for native extensions to be deployed with AIR components.  According to those docs, I would need to have my extension pre-installed on the device by the manufacturer.

While this likely isn’t entirely true (RIM has said in a recent BerryReview interview that native integration is possible though unsupported; and I came across a blog post from Adobe that also said it would be available) … and I”d be tempted to push ahead anyway… the lack of the CPP file means that I can’t actually author an extension to test the theory.

This leads me to the pure OpenGL front-end, which is carrying its own set of headaches:

• there is no UI library that exists for OpenGL which runs on QNX. This means creating things like list controls (for connection, private key, macro management, shortcuts, etc), pop-up windows, entry fields, checkboxes etc from scratch or porting an OpenGL UI library to work with QNX.
• OpenGL itself does not handle window management; and as far as I can tell (I’m still learning OpenGL) it can’t run independently of an OS-specific window management integration layer.  The standard libraries like GLUT have not been ported to work with QNX as far as I can find.

Which means in order to get where I need to go, I need to look into the native windowing functionality of QNX and the  QNX OpenGL integration functions.  (Windowing and integration in this way may not be supported on the PB itself, which is a separate concern)

All in all, this part of the process is turning out to be just as much a headache as I expected it would be I’ve not given up yet, but the going is slow.  I’ll post news when I have it.

Of course, this can only be executed from an ssh session used to connect to the PlayBook — we’re a ways away from an app that you can launch from an icon — but it’s a major first step.  The other thing you might notice here is that I brought my own “libcrypt.so” files.

As it turns out, “libcrypt.so.1″ is not present on the PlayBook device – and this is the library that is  required when building with -lcrypto in the Momentics IDE for QNX.

I cheated a bit by grabbing those ARM binaries from the QNX sdk and including them in my package; then used LD_LIBRARY_PATH to tell the PlayBook to find them in the current directory. I am hoping/assuming that this confusion will be resolved when the actual PB NDK is released. It’s worth mentioning that the other libraries I linked to (-lz, -lsocket, and -lpcap) seem to be working fine.

Meanwhile, up next is a native AIR plugin proof of concept.  This won’t initially be an SSH interface, but just a simple plugin that I can use to demonstrate that it’s possible to write a native extension using the tools currently available.

Wish me luck – as it may not be possible. (A couple of key libraries may be missing from the freely available AIR SDK. )