RE: [dsdp-mtj-dev] Discussion about mtj extension points

[<Arto.Laurila@xxxxxxxxx>]

Title: Discussion about mtj extension points

Hi,

 

Please see the extension definition document (MTJ Implementation Overview v0.1.8.doc) in cvs to get a better view to the existing extensions.

 

Below is a little structured list taken from the wiki page with some functional explanations.

 

• This separates the different device vendors implementations/device platforms to it's own plugins and provides a management layer on top of that. 
• device management: manages the different device platform providers. returns all information related to devices. platforms, runtimes, descriptions, etc.
• device platform provider: holds the each device platform details. environment where the device will be executed. provide service to launch a mtj application

 

• This separates the different device vendors implementations/device platforms to it's own plugins and provides a management layer on top of that. 
• deployment manager: main deploy service, manages the different deployment providers
  • deployment provider: define the deploy function. called by the deployment manager (currently nokia pc suite)

 

• This manages the different security providers
• security management: access a key store. manage information in the key store

 

• This opens the build management, where sub-tasks are under the build provider. 
• build management: manages the different build providers, either Eclipse build or external build (e.g. Ant/Antenna)
• build provider: builds mtj project, returns the steps that needs to be executed in the build process. called by the build manager (currently midp and javame)
  • obfuscation provider: obfuscate on mtj application based an obfuscation configuration
  • packing provider: create a deployment packaged
  • preprocessing provider: used in the fragmentation solution. not clear how
  • preverification provider: preverify an mtj project
  • signing provider: sign and unsign mtj project

 

• This persists the used information, e.g. the plugin enable/disable, used sdk/emulators, etc. so that when opened the project at the next time, the same configuration is activated.
• persistence store provider: general persistence mechanism, stores e.g. the device platform configuration

 

• This provides a way to configure/edit the dependent plugin configuration e.g. from the preference service list, through the same admin interface.
• admin gui provider:

 

• Different supported projects
• ui project: defines the possible types of projects that are supported on mtj (currently javame and midp)

• This deals with the fragmentation management, the ddp deals with the device description services and the dds deals with the database storage
• device description provider: fragmentation management: returns device descriptions (services, configuration, etc)
• device description store: fragmentation management: persistence of device description

 

• This deals with the graphical UI builders, the gui builder management manages the different gui builder providers, which each may have own ui screen rendering provider.
• gui builder management: manages the different UI builder providers
  • gui builder provider: holds the gui builder implementation, e.g. midp gui builder
    • screen engine provider: capsules the gui builder mobile screen engine implementation, used by the gui builder provider.

• Localization is not enabled at this point
• localization provider: localization to all strings used by the mtj ui, 

 

• These I'm not aware of
• drm encoding provider: ??? (maybe used to represents drm encoded midlet suites???)
• libraries: define all libraries that are supported by mtj (probably this deals a bit to the Device Platform management services?)

   

As summarizing this, I propose that the device management and -providers do provide the way for different mobile vendors can have their pluggable separate plugins that are specific to their own implementations. Also the deployment management was planned to have much more details that are vendor specific and therefore are easier to implement in own plugins.

 

The areas that have not so much importance now, seems to be dealing the GUI editors and the fragmentation support. Similarly the localization and admin ui are not so important. 

 

Probably the base discussion will go first through the need on such listed functionalities in MTJ and then towards the deployment model of those selected implementations.

When thinking the deployment model (aka plugin model), one architectural point is that does MTJ capsulate the different vendor specific implementations to own plugins, instead of combining those in few ones.

 

 

-Arto

---

From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Paula Gustavo-WGP010
Sent: 07 November, 2007 23:35
To: Mobile Tools for The Java Platform mailing list
Subject: [dsdp-mtj-dev] Discussion about mtj extension points

Hi,

I added today an initial analysis that i made of the current extensions points that are available on MTJ. I just tried to identify all of them and understand what were their functionality on MTJ context.

I posted it on the mtj wiki together with a section that can be used in 2008 planning.

Please feel free to comment on it. We can try to start our discussion about the MTJ services on top of it.

Thanks,
:)
gustavo