[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-mtj-dev] Mobile SDK import in different environments
|
Some additional comments:
I agree with the statement that UEI
is/should be the agreed-to mechanism for accessing SDKs. However, it has
been my experience with different UEI implementations that each one has
small differences between its UEI implementation and interpretation. The
biggest problem with UEI is that there is no compliance test suite, so
its hard to guarantee that any given "UEI" SDK is going to behave
exactly the way your Generic UEI platform provider expects it to. By not
allowing an extension mechanism I think you'll be restricting the usefulness
of MTJ to a small subset of UEI SDKs that exactly match your UEI
provider. I know that some IBM implementations will have issues as
you mention below, which will be a problem for me.
I don't think the detection mechanism
needs to be as complex as you're making it out to be.
For example, in the discussion under
"Future Releases" you mention adding an SDK detection component
that knows about SDKs. This isn't necessary because that's exactly what
each Device Platform Provider/Importer would do. For example, an IBM WEME
Platform Provider would specifically look for IBM SDK device characteristics
and return a "match" if the provided SDK directory had the right
characteristics. Each provider would do likewise, so there would be no
need for an MTJ "Core" detection component.
A "match" would be indicated
by the fact that an importer returns Device Platforms. If there is no "match"
in importer should return null. A DPP should be careful to return a null
as no match even though it is potentially a UEI platform. For example,
if an IBM WEME DPP were given a Sun WTK directory, it should return null/no
because it isn't an IBM SDK (can be tested by looking for "IBM"
in the uieProperties name/version, or J9 files in bin directory, etc).
In other words, the IBM WEME DPP should "decline"
the directory to allow a different vendor DPP or the generic DPP a chance
to find it.
If all Platform Providers/Platform Importers
did this (detect if a SDK is a "match" and return a Device Platform
if it is or null if it isn't), I would think in almost all cases you would
only end up with 2 possibilities:
- The specific SDK platform (eg IBM,
Nokia, etc)
- The Generic UEI platform
In this case you could either
- ask the user if he/she prefers the
specific vendor's platform or the generic one
or
- automatically give preference to the
vendor platform since that is a closer match
I suppose you could make this be a user
preference (ie pick the best match or prompt).
I think this would work in 99/100
instances
Kevin says more data might be needed
to detect a generic SDK, but you may be able to do this with existing data
since your Generic UEI importer is a "known" quantity to MTJ
by its ID (org.eclipse.mtj.extension.dpp.uei)
Here is a proposed algorithm
- Loop through all DPPs and ask for
the device platforms. You need to loop through all of them, not just until
one returns something
- Each DPP/Importer needs to look at
the directory selected by the user and determine if it is an acceptable
SDK according to its own specific criteria (for example, looking at UEI
version and query info, looking and directories, files, etc)
- If the DPP/Importer does not find
what it is looking for, it returns null for the Device Platforms; if it
does find a match, it creates and returns Device Platforms.
- After looping through all DPPs:
-
If there is one platform, no further action - done.
-
If there are multiple platforms, remove the generic platforms based on
with DPP ID (eg filter out DPPs with ID org.eclipse.mtj.extension.dpp.uei)
- After filtering/removal
-
if there is one platform, no further action - done
-
if there are zero or >1 remaining platforms, prompt the user for selection
I think in most cases you'll either
get one generic UEI platform, or a Vendor SDK platform and a Generic UEI
platform. These cases can be automated and no user action is required.
In the rarer cases, you can prompt the user for selection.
-Andrew
_______________________________
Andrew Sandstrom
Embedded Java Technology Development
WebSphere Everyplace Micro Environment
IBM OTI Labs Phoenix 602-217-2470 T/L
667-2470
| Kevin M Horowitz/Boca Raton/IBM
10/17/2006 11:50 AM
|
|
To
| Mobile Tools for The Java Platform mailing
list <dsdp-mtj-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| Re: [dsdp-mtj-dev] Mobile SDK import
in different environmentsLink |
|
Arto,
We do not need a totally automated solution,
if that solution can resolve to a match that might not work completely.
We can provide a solution that is as automated as possible, and then
allows the user to choose from possibilities. If not, we need to
add more data to the SDKs so that we know which is generic and which is
specific, so that we resolve in favor of a specific solution over a generic
solution, like UEI.
kevin
-----------------------------
Kevin Horowitz (khorowit@xxxxxxxxxx)
IBM Software Group - WPLC
8051 Congress Ave.
Boca Raton, Fl 33487
+1-561-862-2113 (t/l 975)
<Arto.Laurila@xxxxxxxxx>
Sent by: dsdp-mtj-dev-bounces@xxxxxxxxxxx
10/17/2006 04:51 AM
|
Please respond to
Mobile Tools for The Java Platform mailing list <dsdp-mtj-dev@xxxxxxxxxxx> |
|
|
To
| <dsdp-mtj-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| [dsdp-mtj-dev] Mobile SDK import in
different environments |
|
Hi!
Current situation:
As stated in my earlier mails, the automatisation
on importing the mobile SDK /Device platforms is very difficult, if there
is no common communication, nor common SDK functionality.
The UEI has been agreed for creating some
common approaches to access to the different mobile SDKs. Thus the
UEI tries to solve all the differencies among SDK/Emulators, each SDK/Emulator
vendor has done their solution a bit differently.
As the current case is with rel. 0.7 that
there are only UEI based SDK / DPP providers available and the current
development aim is to fix the existing bugs.
I would propose that there are no other modifications
to the DPP-providers than the component owner makes, cause there is ongoing
development with these components without having committed yet to cvs.
All changes should be first agreed in architectural
layer before committing.
Now we should focus in MTJ to stabilize the rel. 0.7 release with it's
agreed content.
Short term fixes:
If in rel. 0.7 the MTJ have to support different
SDKs (e.g. UEI and non-UEI DPP providers), the easiest would be to allow
the DPPs to try to access based on try/error.
All the existing DPPs would be put in an array
and each of them tries to solve the SDK in their turn. I.e. the UEI SDK
would be tried first to communicate with the SDK/Emulator and if not succeeding
then the next DPP would try to communicate.
This approach is easy to implement and easy
to test. We could even get it working for the rel. 0.7.
It also solves the IBM non-UEI DPP case and maintains the current implementation
as much intact as possible before the rel. 0.7.
Future releases:
So, how to add more different DPP providers
to MTJ, could to follow the current architecture. e.g. there could be an
automatic and a manual mode for the actual device platform provider. With
manual mode the developer could select e.g. the non-UEI provider, if needed.
There could also be a small SDK detection
component, which could have some static knowledge about the existing SDK
characteristics, e.g. it could detect when the SDK is from WTK, Nokia,
Ericsson, IBM, Sprint, Motorola, etc. and do some DPP provider activation
based on that.
But, this needs more planning, coding, testing,
etc. and I would wait until we have fixed the current UEI based SDK / DPP
cases.
-Arto
Arto Laurila
Chief Architect
Java and Content Tools, TP
Series 60 Platform
P.O.Box 321 FI-00045 NOKIA GROUP
Valimotie 9, 00380 Helsinki, Finland
)
mobile: +358 50 4876692
(
Office: +358
718076692
(
Fax: +358
718068050
�n *
email: arto.laurila@xxxxxxxxx
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
