Re: [Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

2016-12-01 Thread Sumedha Rubasinghe
Harshan, 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

Re: [Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

2016-11-30 Thread Harshan Liyanage
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

Re: [Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

2016-11-22 Thread Ayyoob Hamza
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

Re: [Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

2016-10-26 Thread Sumedha Rubasinghe
Pretty useful. This also makes the device plugins deployable without restarting the server. I believe we can extend the same to write hot deployable device plugins using Java (no OSGi). On Tue, Oct 25, 2016 at 9:02 PM, Ayyoob Hamza wrote: > Hi All, > > Current structure for

[Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

2016-10-25 Thread Ayyoob Hamza
Hi All, Current structure for device type plugin for WSO2 IoT looks like following: devicetype-plugin | - device manager extension (An OSGi service ) | - api (jax-rs) | - UI | - analytics (descriptors - deployer) However, what goes inside device manager extension component is pretty much a