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 <[email protected]> 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: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495>
>
> On Wed, Nov 2, 2016 at 10:11 AM, Harshan Liyanage <[email protected]>
> 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: [email protected]
>> 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 <[email protected]> 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: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495>
>>>
>>> On Wed, Nov 2, 2016 at 9:54 AM, Harshan Liyanage <[email protected]>
>>> 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: [email protected]
>>>> 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 <[email protected]>
>>>> 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 <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Wed, Nov 2, 2016 at 7:23 AM, Ayyoob Hamza <[email protected]> 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 : [email protected]
>>>>>> 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*
>>>>>
>>>>
>>>>
>>>
>>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
