Hi Prabath, To me, it seems that your proposal is almost aligned with what we can do with an OMA DM <https://en.wikipedia.org/wiki/OMA_Device_Management> supported device type.
In OMA DM, every property or action related to a device type is a resource which we can manipulate and how we can do that is well defined in a device definition file. Is what you propose, having an idea similar to a device definition file in OMA DM protocol? Cheers, Dilan. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. <http://wso2.com/> Mobile: +94766405580 <%2B94766405580> lean . enterprise . middleware On Sat, Apr 30, 2016 at 7:11 PM, Prabath Abeysekera <[email protected]> wrote: > Hi Everyone, > > *Current plug-in architecture of CDM-F* > > If we look at the current plug-in model of CDM-F (1.x), it consists of > three primary components. > > 1. A Class that extends "DeviceManager" interface providing information on > what features/configurations to be managed, what datasources are used for > persisting plug-in specific information, what push notification mechanism > has to be configured for a given device type, device type provisioning > instructions, etc. > > 2. A control API in the form of a JAX-RS service that let's us expose > control operations upon the aforementioned features. > > 3. A UI component providing the front-end of the plug-in related > functionalities > > 4. Optionally, analytics scripts, which is to be taken out of the scope of > a device plug-in. Please refer more info on this in thread "[IoTS] Is it > the right thing to package "analytics" scripts with a plugin > implementation?" in architecture@. > > *Key characteristics of the current plug-in model* > > If we carefully look at the aforementioned model, it has the following > characteristics. > > * A class to "describe" how a plug-in should be modeled and represented to > the core device management framework together with its list of features. > > * A JAX-RS service to expose the features defined by the class above. > > * A UI component that talks to the API described in the above step. > > *How to make it "descriptor-driven"* > > My proposal is that, you can quite easily turn this model into a > "descriptor-driven" implementation, which will greatly enhance the > usability of the device management framework, as below. > > * We don't necessarily need a "java class" to "describe" a plug-in as it > can simply be done with a descriptor-file with some sort of a > framework-provided DSL. The key advantage is that, the whole model is > "zero-code" so, you don't need to be a java developer to craft a plug-in > and put it into the framework. If getting used to a DSL is cumbersome, we > can totally make a Developer Studio plug-in that wraps this DSL and provide > the user with an easy-to-use UI for plug-in composition. > > * The operations that should be exposed as part of the control API can > easily be extracted out of the list of features given in the plug-in > descriptor. We should then be able to auto-generate the JAX-RS together > with the required control-operations during the deployment time of the > descriptor. > > * For the UI too, we should be able to adopt somewhat a combined approach > comprising both auto-generated + manual composition aspects. However, > before we do that, we might need to work on a proper UI abstraction for the > framework, which can then be extended by this sort of a model. > > WDYT? > > If the aforementioned model sounds like a good alternative to the current > plug-in model, I'd like to propose adding this to CDM-F 2.0. > > > > Cheers, > Prabath > -- > Prabath Abeysekara > Technical Lead > WSO2 Inc. > Email: [email protected] > Mobile: +94774171471 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
