Skip to main content

[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>>


Back to the top