RE: [dsdp-mtj-dev] UEI Plugins

[Kevin M Horowitz <khorowit@xxxxxxxxxx>]

Arto,

I have read this several times to try to understand the argument, and am not sure that I do.

Are you saying that you consider the UEI Device Provider to be a generic SDK provider instead of a specific provider for UEI SDKs. If so, the division of the logic is really hard to see in the code itself, and the division should be made clearer so that a separation could be coded if other providers are needed.

I think you should be able to just merge the two plug-ins into one, and if there are alternatives available in the future, you can code them as a extension overriding functionality. I am not proposing merging the code into less source files, although that would make it easier to follow, but instead just eliminating a plug-in that seems to provide no benefit to the architecture. I do agree with Craig that we have to many plug-ins and working with the code, that some of the divisions we have in the design are not necessarily there in the implementation. These two plug-ins can not stand alone, and adding a new implementation will just add dependencies in the code.

Thanks,
kevin
-----------------------------------------------------------------
Kevin Horowitz
khorowit@xxxxxxxxxx
Client Platforms and Technology Development
Workplace Portal and Collaboration Software
IBM - Boca Raton, +1-561-862-2113

<Arto.Laurila@xxxxxxxxx>

<Arto.Laurila@xxxxxxxxx>
Sent by: dsdp-mtj-dev-bounces@xxxxxxxxxxx

04/03/2007 07:09 AM

Please respond to
Mobile Tools for The Java Platform mailing list <dsdp-mtj-dev@xxxxxxxxxxx>

To	<dsdp-mtj-dev@xxxxxxxxxxx>
cc
Subject	RE: [dsdp-mtj-dev] UEI Plugins

Hi Kevin,
 
A good question and I understand your goal.
 
As the basis for our device management is kind a three layer design, where: 
- the model (EMF) provides the needed objects to store the device data,
- the DeviceManagement provides the access to the Core layer and also manages the provider level components,
- the DevicePlatformProvider implements the detail level device / SDK features.
 
In the starting point of the MTJ planning there were some analysis showing that there could be also other communication ways against the devices/SDK's (other than the UEI, there was mentions about XUEI etc).
The current development has been focusing to tackle the UEI based device/SDK access and there has not been any further discussion around the possible other technologies. Thus, now it seems more obvious that we (MTJ) has to have reservations for possible other kind of communications against the device/SDK. As heard e.g. from Christian (Motorola), that they do have a strong need for a more detailed and direct communication against the SDK, than the UEI provides currently. And it may be similar case also with Nokia.
 
Based on the above, there may be cases, where we should have a set of different plug-ins that do provide the needed access to the SDK's, with the scenario of their different versions. 
 
If we e.g. bundle the UEI inside the DPP and do not allow that the different protocol implementations are in separated plugins, we may end up to a situation where we do have a fixed, monolithic approach, where the adaptation to new set of implementations is very difficult.  
 this component is probably having the most dynamic changing reqs in MTJ and I would try to keep it's architecture/design as dynamic / open as possible.
 
So, as conclusion, if staying with the current one DPP approach, no.
 
What opinions do others have?
 
-Arto

---

From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Kevin M Horowitz
Sent: 28 March, 2007 17:17
To: dsdp-mtj-dev@xxxxxxxxxxx
Subject: [dsdp-mtj-dev] UEI Plugins

I am looking at our tree structure for some changes in the runtime executable category and was wondering why we maintain two plug-ins to support the UEI code.
We have org.eclipse.mtj.executable.uei and org.eclipipse.mtj.extension.dpp.uei. The second plug-in is mostly a wrapper for a device provider whose functionality is
call contained in the first plug-in.

I think we should look at merging these into the DPP plug-in and eliminate the other.

What are your thoughts?

kevin
-----------------------------
Kevin Horowitz (khorowit @ us dot ibm dot com)
IBM Software Group - WPLC
8051 Congress Ave.
Boca Raton, Fl 33487
+1-561-862-2113 (t/l 975)_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev