[
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 Jon
As far I can understand the concept proposed by craig, the SDKprovider
should known how to find it's devices in the user filesystem. For
example, let's say that the WTK is installed; it writes to the windows
registry an entry with the path to its sdk home folder. The WTK
SDKprovider should know a way to read that entry, and when requested,
return the list of devices available in that folder.
Since we will have a feature freeze on May 4th, M7 release, I believe we
won't have enough time to implement the approach proposed by Craig. So,
at least for this release, we should maintain the deviceimporter E.P and
try to implement that refactory on a feature release.
We must implement some approach for the SDK install, which one should be
best for now, taking in consideration the small timeframe?
What is your opinion on the proposed SDK install feature? Does anyone
have a better idea, suggestions, and concerns?
Diego
-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Jon Dearden
Sent: Wednesday, April 29, 2009 2:44 PM
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] My Proposal for the SDK extension point
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
