[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [dsdp-mtj-dev] My Proposal for the SDK extension point
|
Hi Craig,
I like the idea of grouping the devices by a SDK instance but I have a few questions.
Following this approach we wouldn't need the deviceimporter E.P anymore, is that correct? Or we should provide the two ways of importing devices into MTJ?
If we don't have a deviceimporter, we wouldn't need the deviceregistry anymore because we would use a sdkregistry. that would be trick to achieve by M7 we use a lot of the deviceregistry in the code and i believe we wont have enough time to implement this changes by next week.
I believe that would be better for our clients to make a simpler version of the SDK E.P for this release and make this structural changes for the next version. I was thinking something like this sdk E.P should have a way to clients specify a list of folders and a deviceimporter id to be used for scanning for devices. we can also add a class to be implemented as a deviceprovider.
I see this is not the better solution, but would work for now on most cases and would impact the less on MTJ. We would also have time to implement it and test.
I'm suggesting this approach because from my point of view if a client would like to include his devices on mtj, he would be already working on a device importer by now, and most of the work would be lost if we adopt this changes so late in the API.
Please, Jon could you give your opinion in this matter? David, Gorken your opinion would be also very welcomed.
Cheers
Diego
-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx on behalf of Craig Setera
Sent: Sun 4/26/2009 5:23 PM
To: Mobile mailing list Tools for The Java Platform
Subject: [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
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
<<winmail.dat>>