02-16-2011 03:46 PM
Currently, there is no easy way to have a common data store between two unique applications.
SharedObjects might work but without the Flash Media Server, there is not synchronization or notification.
PPS might work (publish subscribe), but there is no API for it (though the service is available on the OS), but there is a file size limitation and is really only meant for meta information.
There is no database server (SQLite is an inprocess database API), but even that does not allow for synchronization and notification.
The only thing that I have come up with is to have an API (and library) that manages the datastore. Since we're lot allowed to have services, the datastore would be XML files but they are hidden from the client via the API. API would allow DB like features, but may or may allow for locking. On change, the API could UDP so other applications (via the API) would get notified on changes. Could have that if the application is not active, that it cannot do writes and eliminate the issue of simultaneous writes to the same file avoid lock conditions that dont clean up after themselves.
Think in context of contacts, and calendar events. We have no word of a native contact manager and even if there is, we're not certain if it is only for BB phones, if it has an open API and if it is extensible.
02-16-2011 04:12 PM
Good question... I'll respond first just by responding in sequence to several of your paragraphs.
I happen to believe the PPS stuff will and should be at the heart of much of this, partly because I believe it will be a real differentiator between the QNX stuff and the competition. As you say, though, it's not directly applicable because of several limitations.
SQLite would actually work quite well in some ways to share data between apps... two apps can certainly interact with the same SQLite database at the same time... there's no need for a server since this is all on the same hardware. There are limitations there too, but the main ones are notification (as you noted), and that unlike "true" SQL server-based databases, you can't have multiple simultaneous writers. Other than that, however, I don't think "synchronization" is a problem for SQLite, depending what you meant by that.
We will, at some point, presumably, be allowed to have services. I think they simply haven't got the manpower or marketing goals figured out enough yet to be able to define how that should work.
One key problem that may be a deal-breaker for some uses of this is that, for the moment, there is no way to have two apps share data which is not available to all apps. I doubt it would be very hard for them to support it, actually, with a way of having multiple apps from the same vendor somehow register a shared resource that they can access but no "stranger" apps can access.
For now, the shared/ folder would be the obvious place to store the data. I would picture, as you suggested, an API to mask many of the details, including the actual data storage format. I wouldn't use XML, or at least not only XML. I'd try to support AMF3, which is what the SharedObject stuff uses, but also raw files, SQLite database(s), and at that point XML can be thrown in on top.
The PPS stuff would certainly be helpful here as the channel for metadata, given both the publish-subscribe parts and the persistence part.
I actually believe its likely the contact/calendar stuff will be available for non-BB use sooner rather than later, and that it will have a documented API and be available to us. I think there will also be other documented mechanisms based on PPS that will let us build our own APIs for inter-app messaging on top of it, possibly building on a general-purpose library of support routines and/or a service to facilitate it.
Unfortunately, I don't believe it will be available in the next couple of months, meaning specifically at release or shortly after. I haven't decided yet if it's a good idea to forge ahead in that area without waiting for a sign from RIM. (I suspect they've never considered the possibility that us little guys out here who don't pay them $Xk per year may be capable of advancing things in that area, but maybe if we start on it they'll pipe up to ask us to hold off a bit.)
02-16-2011 05:13 PM
Thanks for your comments and suggestions. It is not an immediate need for me, but it is around the corner. When other capabilities (PPS, services) come on line, I hope what ever solution I forge will be adaptable.
Back in the day, a little known OS (BeOS) used a repository of files to hold information like contacts, bookmarks, etc for all apps to share and extend as needed. It worked very well so when a user switched from one app to another, they did not lose or have to re-enter all the information again. It made for a powerful selling point for the whole OS and allowed developers to bring solutions online faster.
Just brain storming for now.