| [dsdp-mtj-dev] My Proposal for the SDK extension point |
Hi guys,I was able to come up for air from work for just a bit this weekend and wanted to take a crack at getting my ideas for the SDK extension point together for everyone to consider. I've created a new branch in SVN (https://dev.eclipse.org/svnroot/dsdp/org.eclipse.mtj/branches/craig_sdk_work/org.eclipse.mtj.core ) containing my initial thoughts on this. You can use the Eclipse compare functionality to compare what I've got versus the current trunk implementation.
There are some basic concepts in play with this proposal. Thinking about how I think RIM might want to build out an extension for registering devices, it seems to me that they don't want to do registrations one SDK at a time. In general, they want to have a a "Blackberry SDK Provider". Thus, the root extension point is ISDKProvider instead of ISDK as we had originally discussed. This way, RIM can have one extension to manage all of the SDK's installed on a machine. As previously discussed, an ISDK would then be responsible for managing a set of IDevice instances. Those are the basics of the proposal.
In addition, I'm suggesting that all devices would now be managed by an instance of ISDK. I've created a PersistentSDK abstract skeleton that could act as the superclass for UEIPersistentSDK and MIcroemuPersistentSDK. When it is time to load and store devices, that would all happen via the SDK. If the SDK wants to manage these things outside of our persistent storage, then the load and store methods would be ignored by these SDK's.
Please take a look and let's have some discussion on this proposal. We need to decide where this particular set of functionality is going very soon so that it can be built out and tested well enough. Not to mention, I'm sure that we have a few consumers waiting for something like this.
Thanks, Craig