Thanks for the note and for sharing your experience — it really is very valuable for me to hear what things would help make the documentation (and the product) better for you.

As I suggested in the post, I’ve made some changes in the documentation for the AIR local SQL database — it now says that it’s SQLite in the first paragraph (the first sentence I think), plus I added a section on some of the differences between the AIR implementation and the SQLite implementation as described in the SQLite docs.

These changes will be included in the next public release of AIR.

(I had to smile at the mental image of the “seamlessly inherited halo” — thanks for that, too =)

Mentioning SQLite in Adobe’s documentation would give me a very positive and immediate impression of AIR.

I would know to skip that whole section because it’s already rote in my mind, and AIR would seemlessly inherit the halo that hangs above SQLite.

Case in point…I wanted to add search to my AIR based offline forum just like my online forum has. That gets a bit tricky in this environment because I lose the benefit of PHP where crossing tables and nesting queries is a no brainer. Long story short I work out a routine to do just that. In my example I need to search all post bodies for a term. Since I display posts with an item renderer it’s stupid to simply display the result data from the post body search query because I will end up with a massive list of posts that are harder to correlate what forum or thread they belong to when a user chooses to reply (which can be done but visually they would have no idea what forum or thread they were responding too since all results are lumped as one). Instead I want to take the data from the post search query and re-use it for a nested search against thread titles and display the results via the parent thread (which it does) so I can grab the associative data (not shown to the user) when they normally choose a thread to display so my outbound post data is correctly inserted in the correct forum and correct thread depending on what they reply to when they sync their local board.

Now….with this final result set from the two nested queries, I could just as easily filter how it’s displayed (the order… like a full text search would offer) using a sortOn method. For instance list it by name alphabetically and then by date (or whatever) based on data returned from both queries individually or in conjunction….no?

I get a headache thinking about it but here are screenshots of the board and one of the nested query returning (it’s the first screen shown)

http://www.flex-fanatic.com/index.php?cid=3&did=215

displaying the final result and I wholly plan on seeing if my thoughts on this fly once I finish this project. I have a feeling that our being able to rely on AS3 may have some benefit for whatever is lacking in “our wish lists” :)

Fair enough :)

If I jumped to an incorrrect conclusion on your agenda, I sincerely apologize.

On the SDK’s, I’m content that we agree to disagree. :)

As for the future, I’m really interested in Paul’s latest article regarding encryption. Now this is something I would like to see become internally handled by AIR as opposed to an external class addition (much like I prefer an internally handled SQL database as opposed to a third party (Artemis) implementation) so it’s less confusing to new users and lets us become more of a viable choice (a choice mind you….not saying they should switch or would want to:)) for current users of commercial wrapper tools. I’ve really hinted to this for a long time in alpha and hope I’m happily surprised to see it come on board just like I was to see SQLite appear in beta (and where previous stage indications were it would not or was not part of the roadmap).

Chris

If you read my post, you’ll see that I make it quite clear that Adobe is open about its use of SQLite - I even linked to the press release. My point was that SQLite is not credited in the documentation. Paul’s response above shows that this is an interesting issue, I don’t need to defend the point further.

I don’t intend to be either friend or foe to a particular vendor, either one would be a failure.

I still think the SDK download options are confusing, but I’ll happily agree to differ. That doesn’t mean any hidden agenda though.

Tim

You’re absolutely right that it doesn’t cost any money, and only a trivial amount of file size and space, to acknowledge that AIR uses SQLite for its database engine.

What I was hoping to communicate was that file size and money aren’t the only considerations that I and others had in mind when we considered the issue. Unfortunately, there is a real legal obligation that comes along with making something explicit in our documentation, different from mentioning it in a blog, discussion list, etc. Is the risk from that obligation (and other possible negatives) worth the downside of not giving acknowledgment to SQLite’s authors? That’s the tough question we had to face — ironically if the licensing terms were different we wouldn’t have had to make that choice =). So we did make a choice; perhaps it was the wrong one; fortunately we have an opportunity to reconsider our choice.

As a side note, one of the reasons Adobe chose to use SQLite was because there is an opportunity to “give back” any improvements that might be made. If the licensing terms had been different for SQLite, I think it would have been much less likely that Adobe would have chosen SQLite (my opinion — I’m definitely not the one who makes those choices). Likewise, Adobe has stated that WebKit was chosen as the HTML engine in part because it’s an open source project and improvements can be contributed back.

On top of that, we were always aware that, whether or not it was explicit in the documentation, word would get out that AIR’s database engine is based on SQLite. Personally I’m very glad that the word got out sooner rather than later — I’ve got tremendous respect for SQLite and the effort that’s gone into making it great, and I’m hoping that the benefit will work both ways — Adobe gets a great database runtime, and SQLite gains more public awareness and recognition since some big players (Google and Adobe) have chosen SQLite.

I also agree that I don’t think Adobe has to meet any expectations as compared to Google Gears in regards to SQLite changes or alterations. I really don’t think Gears is using an out of the box SQLite implementation either and since Adobe already had a round of this type of rhetoric with how they would change or alter Webkit and if it would be shared with the community (which it will be)…I don’t see Adobe having a bad record on sharing or exposing alterations or implementation based on opensource tech. I’m sure they will handle the SQLite community as graciously as they will the Webkit community.

On confusion….if I am a Flex developer or an Ajax (etc) developer, how is choosing the correct SDK confusing? It’s not as if they have to be run simultaneously or you have to switch back and forth. Ajax coders have no need for the Flex implementation and Flex users the same in reverse. Your paragraph seems to indicate a jumbled mess and I don’t see it as such. I’m pretty sure devs will know which SDK applies to them and never have to worry the unchosen one. The fact Adobe put the extra effort into making the experience specific to the SDK chosen is a plus IMO..not a minus….and surely nothing resembling confusing. I don’t mean to make an enemy of you but by the time I finished your first paragraph, I looked back up to see if you were affiliated with M$ because I could swear it was conceived by someone with an agenda to dissuade users from AIR. Sorry if I called it wrong but with so many players in the game you are either friend (who may wish for things or want to suggest things) or foe (who looks for every opportunity to blacken an eye with even the silliest of reasons…some of which are unfounded but as long as they get snaked by search engines are effective).

Chris

Perhaps what Adobe wanted to do is make believe that no one needs to know they use external 3rd party opensource code, this can discredit the company. It’s how marketing guys thinks/works. But doing so and don’t saying nothing in documentation discredit Adobe.

Well, perhaps I am easily confused. I have no axe to grind though.

AIR has two personalities. One is for browser apps, the other is for Flash apps (coded with Flex), both running on the desktop. Hence two separate SDKs. That’s the fact I wanted to reflect in my opening paragraph.

I’d be grateful if you could clarify why this or any other part of my post is a “cheap shot”, also please explain the hidden agenda you allege?

I agree though that Paul’s response is really helpful and encouraging.

Tim