Re: [dsdp-mtj-dev] Mobile SDK import in different environments

[Craig Setera <craigjunk@xxxxxxxxxx>]

Note that this is essentially the way that EclipseME handles the
problem. The only added complexity is that EclipseME allows a priority
specification on the device importer with the highest non-null importer
"winning". In this case, the generic UEI functionality would be given a
lower priority and would therefore lose if there was a Vendor provider
with a higher priority.

Andrew Sandstrom wrote:
>
> 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
> <Notes://D03NM132/87256C9500070E7E/38D46BF5E8F08834852564B500129B2C/F08D1CEA28032A8C8725720A0030AC8C>
>
>
>
>
> 	
>
>
>
>
> 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@nokia.com__
> _ _______________________________________________
> 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
>