RE: [dsdp-mtj-dev] UEI Plugins

[<Arto.Laurila@xxxxxxxxx>]

Hi Kevin,
 
To be more precise, I'm not sure that the UEI will be the generic SDK
provider in the future.
That brings us to a situation where we have to support several different
SDK access architectures and 
on that situation I would like to separate the different solutions to
own plugins.
 
The current MTJ does have pretty well separated all the different
features to their own plugins. 
Maybe there are some plugins that do have unnesserily separated the UI
also to its own plugin, but as
seeing the current MTJ plugin architecture, it drives the whole
development to a direction where it's 
dependency structure is quite manageable.
 
As the main criteria, at least for me, is that the component model
should be such that the future development is easy and
its easy to do changes without causing large re-factoring works. If the
dependency model supports this kind of atomic 
development and provides a updateable component model, where are rather
easy to do estimates based on the dependency model. 
The Cathedral-and-the-Bazaar discussion opens a bit this kind of
thinking. It is rather common to follow the "Cathedral" like (i.e.
Monolithic)
sw architecture path. But for me, the Bazaar -like sw architecture means
here that there are also take account that the development is done 
by rather unknown developers against small components.
 
The difference over here is that on the Cathedral -model, the sw is
easier to manage if there are one (or few known) developers, but that
has a 
risk that it's rather difficult to change due it's monolithic dependency
model.
By having a small components (Bazaar), the amount of plugins surely
grows, but the detail development is done against small components which

dependencies are known. To accieve the more dynamic sw architecture, we
have to enable it by separating features and doing rather small 
components.
 
I do have actually two different external tools that enable to analyze
the MTJ dependency model. 
I have Lattix and Structure101, which both do enable to view and analyze
the component dependencies.
There are some issues, that I would like to fix in the current
componentmodel, but as the development is ongoing now, it's easier to
focus to
major development tasks and do the DSM fixes later.
 
-Arto
 

________________________________

From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Kevin M
Horowitz
Sent: 12 April, 2007 17:44
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] UEI Plugins



	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