Sorry about that. I thought this needs to be done after the device identity thing which we talked about doing with IS roadmap.
Regards, Dilshan On 29 April 2016 at 13:53, Prabath Abeysekera <[email protected]> wrote: > Well, supporting device identity is indeed something that's there in the > product roadmap. However, that I'm afraid is out of the scope of what's > proposed and intended to be discussed within this particular thread. > > That said, if you are willing to contribute to the platform WRT getting > device identity implemented, and also have got a design/architecture in > mind, please do go ahead and initiate a separate thread in architecture@, > so we can discuss it there. > > Cheers, > Prabath > > On Fri, Apr 29, 2016 at 10:25 AM, Dilshan Edirisuriya < > [email protected]> wrote: > >> 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 >> >> > > > -- > 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
