| Re: [dsdp-mtj-dev] Mobile SDK import in different environments |
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
|
|
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
