Yes.. in the feature definition xml I sketched out, there are multiple criteria under <FilteringCriteria> tag.
On Wed, Nov 2, 2016 at 2:55 PM, Chathura Dilan <chathu...@wso2.com> wrote: > Hi Chathura, > > How about having multiple criteria under one feature so we can better > address all the scenarios. > > > On Wed, Nov 2, 2016 at 12:36 PM, Chathura Ekanayake <chath...@wso2.com> > wrote: > >> Regarding sensors, we can consider them as features, where the action >> they support is "read value". If we are using polling method to trigger >> operations, read operation can have a parameter with an endpoint to send >> sensor reading. >> >> - Chathura >> >> On Wed, Nov 2, 2016 at 12:30 PM, Chathura Ekanayake <chath...@wso2.com> >> wrote: >> >>> I think we can define a feature (or an operation) with: >>> >>> A) Feature code - to identify the feature >>> B) Filtering criteria - to identify devices which can perform the >>> operation >>> C) Operation parameters - Additional details needed by the operation >>> >>> Restriction criteria such as device type, group ID, device version >>> (better a range of versions) can come under B. So whenever an operation is >>> invoked, IOT platform should evaluate device details against B and decide >>> whether to permit the operation. If permitted, it can get C from the user >>> (or from an external system) and add an operation record in DB with A and C >>> against the device ID. >>> >>> With this we can use feature schema similar to what Ruwan has proposed: >>> >>> <Features> >>> <Feature code="abc"> >>> <Name>abc</Name> >>> <Description>this is a feature</Description> >>> <FilteringCriteria> >>> <Criteria name="deviceType">DT1</Criteria> >>> <Criteria name="version">[2.0,3.5)</Criteria> >>> </FilteringCriteria> >>> <FeatureProperties> >>> <Property name="prop1">place_holder</Property> >>> <Property name="prop2">place_holder</Property> >>> <Property name="prop3">place_holder</Property> >>> </FeatureProperties> >>> </Feature> >>> </Features> >>> >>> Regards, >>> Chathura >>> >>> >>> >>> On Wed, Nov 2, 2016 at 10:41 AM, Ayyoob Hamza <ayy...@wso2.com> wrote: >>> >>>> @Harshan, agree its a concern. Location/DeviceInfo/ApplicationList >>>> operation triggers even if the device doesn't support it. we need to make >>>> this device type specific. >>>> >>>> *Ayyoob Hamza* >>>> *Software Engineer* >>>> WSO2 Inc.; http://wso2.com >>>> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495> >>>> >>>> On Wed, Nov 2, 2016 at 10:11 AM, Harshan Liyanage <hars...@wso2.com> >>>> wrote: >>>> >>>>> Hi Ayyoob, >>>>> >>>>> Yes you are correct. But I took the barometer as an example. However >>>>> there may be real scenarios where some devices does not have GPS so that >>>>> we >>>>> can't access the location info. In such cases we need to disable >>>>> "Location" >>>>> operation for those devices. >>>>> >>>>> Thanks, >>>>> >>>>> Harshan Liyanage >>>>> EMM/IoT TG >>>>> Mobile: *+94765672894* >>>>> Email: hars...@wso2.com >>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>> lean.enterprise.middleware. >>>>> >>>>> On Wed, Nov 2, 2016 at 10:07 AM, Ayyoob Hamza <ayy...@wso2.com> wrote: >>>>> >>>>>> @Harshan, sensors are not part of features(correct me if I am wrong), >>>>>> This is why there was a requirement raised for sensor management as part >>>>>> of >>>>>> device management and we had an implementation to support this(from >>>>>> shabir) >>>>>> which is not merged yet. >>>>>> >>>>>> [1] https://github.com/wso2/carbon-device-mgt/pull/407 >>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fwso2%2Fcarbon-device-mgt%2Fpull%2F407&sa=D&sntz=1&usg=AFQjCNGLqXZzNEVnTBLB5rugQeJWfFmnNQ> >>>>>> [2] https://github.com/wso2/carbon-device-mgt-plugins/pull/394 >>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fwso2%2Fcarbon-device-mgt-plugins%2Fpull%2F394&sa=D&sntz=1&usg=AFQjCNFHWDeJJW5WCMCeENFnDo6271makQ> >>>>>> >>>>>> >>>>>> *Ayyoob Hamza* >>>>>> *Software Engineer* >>>>>> WSO2 Inc.; http://wso2.com >>>>>> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495> >>>>>> >>>>>> On Wed, Nov 2, 2016 at 9:54 AM, Harshan Liyanage <hars...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Dilan, >>>>>>> >>>>>>> +1 for the idea. But we also need to consider the device model when >>>>>>> comes to the features. For example there may be Android devices where >>>>>>> some >>>>>>> sensors like barometer is not present. This will be mostly applicable to >>>>>>> the mobile device types because IOT devices will have their own plugin >>>>>>> independent of the device model (correct me if I'm wrong). >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Harshan Liyanage >>>>>>> EMM/IoT TG >>>>>>> Mobile: *+94765672894* >>>>>>> Email: hars...@wso2.com >>>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>>>> lean.enterprise.middleware. >>>>>>> >>>>>>> On Wed, Nov 2, 2016 at 9:14 AM, Jasintha Dasanayake < >>>>>>> jasin...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi All >>>>>>>> >>>>>>>> Yes.. , engaging with a plugin repository like eclipse vorto would >>>>>>>> be great idea for IOT , we can provide set of extension point (we may >>>>>>>> already have) where custom plugins can be plugged in >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> /Jasintha >>>>>>>> >>>>>>>> On Wed, Nov 2, 2016 at 7:53 AM, Ruwan Yatawara <ruw...@wso2.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Nov 2, 2016 at 7:23 AM, Ayyoob Hamza <ayy...@wso2.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> different >>>>>>>>> >>>>>>>>> >>>>>>>>> I am with Ayyoob in that the term "feature" sounds very much >>>>>>>>> something from the mobile world. But if you think about it, any >>>>>>>>> functionality that a user sees on the dashboard of a device type is a >>>>>>>>> feature. So I am +1 for bringing feature definition down to the mobile >>>>>>>>> plugin in form like. >>>>>>>>> >>>>>>>>> <Features> >>>>>>>>> <Feature code="abc"> >>>>>>>>> <Name>abc</Name> >>>>>>>>> <affectedVersion>5.0.0</affectedVersion> >>>>>>>>> <Description>this is a feature</Description> >>>>>>>>> <FeatureProperties> >>>>>>>>> <Property name="prop1">place_holder</Property> >>>>>>>>> <Property name="prop2">place_holder</Property> >>>>>>>>> <Property name="prop3">place_holder</Property> >>>>>>>>> </FeatureProperties> >>>>>>>>> </Feature> >>>>>>>>> </Features> >>>>>>>>> >>>>>>>>> But somewhere down the line when it comes to orchestrating device >>>>>>>>> integration flows, we most definitely as Ayyoob mentioned, have to >>>>>>>>> take a look at Vorto... which is very cool IMO. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks and Regards, >>>>>>>>> >>>>>>>>> Ruwan Yatawara >>>>>>>>> >>>>>>>>> Associate Technical Lead, >>>>>>>>> WSO2 Inc. >>>>>>>>> >>>>>>>>> email : ruw...@wso2.com >>>>>>>>> mobile : +94 77 9110413 >>>>>>>>> blog : http://ruwansrants.blogspot.com/ >>>>>>>>> https://500px.com/ruwan_ace >>>>>>>>> www: :http://wso2.com >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Jasintha Dasanayake**Associate Technical Lead* >>>>>>>> >>>>>>>> *WSO2 Inc. | http://wso2.com <http://wso2.com/>lean . enterprise . >>>>>>>> middleware* >>>>>>>> >>>>>>>> >>>>>>>> *mobile :- 0711-368-118* >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > > -- > Regards, > > Chatura Dilan Perera > *Associate Tech Lead** - WSO2 Inc.* > www.dilan.me >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
