Hi, What are the plans to support device identity? There are several situations where you need to consider device as a top level element rather than associating it with users. Eg; picking the device from authentication level, adding throttling policies for device etc.
Regards, Dilshan On 28 April 2016 at 17:56, Prabath Abeysekera <[email protected]> wrote: > Hi Everyone, > > As all know, CDM-F is a platform that allows folks to easily extend its > plug-in model and seamlessly add support for new device types. So, ATM, > "Device Management Plugin" is the primary top level construct that can be > extended in the framework, to cater the aforementioned requirement. > > I'm proposing "Device Management Feature" too should be treated as a > similar top-level extensible construct, particularly considering "EMM-like" > scenarios, in which we ship a standard set of plug-ins, that needs to be > extended to support a few new features. Here's why. > > Let's assume an organization is planning to deploy EMM to manage their > devices. The list of "features" that needs to be managed by one > organization might vary from that of another. Further, support for managing > some of those might not even be available OOTB as part of EMM. To makes > things more complicated, in certain cases, shipping all that sort of fancy > features around OOTB in EMM wouldn't quite make sense as well. However, in > the context of those adopting organizations, having the ability to control > such features might be critical. As a result, there is always a possibility > that these folks get lured into customize the existing functionalities if > that level of extensibility is not available in the product. > > To cater the aforesaid requirement, the only option available right now is > extending one of the existing plug-ins (with the new features) and then > plugging the enhanced plug-in back into the product, which is somewhat a > tedious task. > > To make things more easier for users, I propose making "Device Management > Feature" an extensible construct, which can be utilized by the folks who > want to extend an existing plug-in to seamlessly support new features that > are not supported OOTB in the product. This can be thought of as something > similar to the concept of "mediators" in the context of ESB as well. > > WDYT? > > 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
