The purpose of descriptor was to remove boiler plate code. If there is
anything specific, use the handwritten plugin approach.
If it's not already there, let's make both descriptor and handwritten
plugin to co-exist on a single runtime.
On Thu, Dec 1, 2016 at 1:25 PM, Harshan Liyanage <hars...@wso2.com> wrote:
> Hi Ayyoob,
> There are some instances where we need to cater plugin-specific
> functionalities which can't be achieved through a boiler-plate
> implementation. This behavior can be seen in mostly mobile-device plugins.
> For most of the times we don't need specific internal implementation. For
> example sometimes we need to store some device data in plugin database
> table and fetch it using a specific query. How are we planning to move
> forward in such scenarios? Can this deployer generate tables other than
> device table and feature table? If not I suggest to add following
> capabilities to the deployer model.
> - Ability to specify custom tables
> - Ability to specify custom queries/DAOs
> - Extension model where we can specify custom implementations which
> are required for the device plugin
> Harshan Liyanage
> EMM/IoT TG
> Mobile: *+94765672894*
> Email: hars...@wso2.com
> Blog : http://harshanliyanage.blogspot.com/
> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
> On Tue, Nov 22, 2016 at 10:10 PM, Ayyoob Hamza <ayy...@wso2.com> wrote:
>> Hi Dilan,
>>> Does this mean we can basically have a ready-to-use device plug-in
>>> implementation, just by configuring a descriptor file ?
>> Yes thats the idea, In here the plugin means the osgiService which
>> contains the definition of the device type. we found from the existing
>> device type that it all follows the same implementation template as the
>> plug-in(DeviceManagementService) implementation. Therefore I created a
>> generic template which populates the DeviceManagementService through a
>> configuration file.
>> Architecture mailing list
> Architecture mailing list
m: +94 773017743
b : bit.ly/sumedha
Architecture mailing list