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,

We are OK to postpone this E.P for RC1 according to http://dev.eclipse.org/mhonarc/lists/dsdp-pmc/msg01703.html.

I'm starting to work on this today. Probably next week I will have a first useful implementation for testing.

Cheers
Diego


-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx on behalf of Sandin Diego-WDS057
Sent: Wed 4/29/2009 2:09 PM
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] My Proposal for the SDK extension point
 
I like the idea of the sdk refactory, I'm just concerned about the
timeframe, but if everyone agrees with that approach I'll have to start
working on it quickly.

We can also manage to create ourselves an sdk instance for each sdk
listed on the found devices from the device importer.

Diego

-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Wednesday, April 29, 2009 2:49 PM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] My Proposal for the SDK extension point

(Sorry guys... buried today)

I am not suggesting getting rid of device importer.  I think it  
continues to make sense with or without the SDK stuff.  My only  
suggestion was that under the covers we re-cast device importer to  
create instances of SDK to keep the model consistent.   I'm concerned  
that if we don't make this change now, it will be very difficult in  
the future.  Because device has a connection to an SDK... we can't  
just add that later without breaking all current IDevice  
implementations.

The assumption has always been that an SDK provider would know how to  
find their SDKs... whether it is a well-known location on disk,  
registry entry or something else.

In quick summary... whether we actually provide the SDK/SDK provider  
extension point, I think we need to get an SDK model object in place  
or we won't be able to in the future without breakage.

Craig

On Apr 29, 2009, at 12:44 PM, Jon Dearden wrote:

> Diego,
>
> I am not in a big rush to see a change to the device importing. We  
> need
> to get there, but what we have now works. My question about the SDK
> approach is that the SDK provider needs to know the location of his
> SDKs. Does that imply the need for an installer on the part of the SDK
> provider?
>
> Is there any value in keeping both import approaches going forward?
>
>
> Regards,
> Jon
>
> -----Original Message-----
> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Sandin
> Diego-WDS057
> Sent: Wednesday, April 29, 2009 9:26 AM
> To: Mobile Tools for The Java Platform mailing list
> Subject: 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
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain  
> confidential information, privileged material (including material  
> protected by the solicitor-client or other applicable privileges),  
> or constitute non-public information. Any use of this information by  
> anyone other than the intended recipient is prohibited. If you have  
> received this transmission in error, please immediately reply to the  
> sender and delete this information from your system. Use,  
> dissemination, distribution, or reproduction of this transmission by  
> unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

<<winmail.dat>>


Back to the top