Hi Prabath, +1, thought the same that we should map our existing model to a developer easy model.
> > 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. > This is an eclipse based project where we can get some ideas on how we can stream line this or rather if possible we can create a support for this[1]. > > * 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. > Just wondered since we have a common operation api, which can be used, but the concern is that the apis are very low level and where-in a device type should be able to represent its APIs in an high level form. Therefore I wondered whether we could go for generating custom in-sequence approach rather implementing a jax-rs ?. [1] http://www.eclipse.org/vorto/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
