Hi Ayyoob Thanks for the valuable feedback. Please see my comments in line.
On Sat, Apr 2, 2016 at 10:32 PM, Ayyoob Hamza <[email protected]> wrote: > Hi Geeth, > Looks cool and as my understanding I see that there are two capabilities > that has been described here. > 1) Trigger operations through tasks. > 2) Searching devices based on its attributes. > I assume, in the dynamic case what we do is to keep the last snapshot of > the data. which in the server perspective is just an attributes that are > stored in DB and we make a search based on the search criteria . > > As my understanding of the context I have following doubts, please find it > inline. > > >> >> These operations can be configured using the cdm-config.xml. As of now we >> have configured 3 operations (Device info, application list, device >> location) for default pack. If any user needs to add more operations, they >> will be able to do that easily, just by adding a simple <Operation> >> configuration in TaskConfigurations. >> > Why do we need to have default operations and why its been applied to all > devices?. > In the context of EMM these operations are acceptable, but not in the level of IoT. So those operations are described in as needed for EMM, When we release IoT server, we will keep this fields empty. IMHO, I believe by default it should be empty in CDMF level and in product > level we can specify this configuration and also IMO I think its better to > have another element called "DeviceTypes", which could be used to mention > either to apply to specific device type or set of device types or else if > it is not mentioned then it can be applied to all device types. This could > provide the capability for device type authors to trigger server side > operations. > +1 for above, That will be a great improvement which we should add to roadmap. Yes, we need to consider device types while adding those operations. Because not all device types are support the all the operation, different device types supports different operations. So we need to extend this feature to get the related operations from device type plugin. > > >> >> *<TaskConfiguration>* >> * <Enable>true</Enable>* >> * <Frequency>600000</Frequency>* >> * <Operations>* >> * <Operation>* >> * <Name>DEVICE_INFO</Name>* >> * <RecurrentTimes>1</RecurrentTimes>* >> * </Operation>* >> * <Operation>* >> * <Name>APPLICATION_LIST</Name>* >> * <RecurrentTimes>5</RecurrentTimes>* >> * </Operation>* >> * <Operation>* >> * <Name>DEVICE_LOCATION</Name>* >> * <RecurrentTimes>1</RecurrentTimes>* >> * </Operation>* >> * </Operations>* >> * </TaskConfiguration>* >> >> Frequency is how often the task runs. RecurrentTimes defines how often >> the operation should be added to the task. Example: If user defines the >> value as 5, it indicates that task add the operation at every 5th run. When >> operations are added to database, devices will be notified to retrieve the >> operations. Then devices will sends the responses to operations. >> >> 1. DEVICE_INFO : As the result for this operation, device should send >> it's device information such as device name, cpu usage, memory usage, >> available memory, >> 2. APPLICATION_LIST : This operation will send the list of the >> application installed in the device including application memory usage. >> 3. DEVICE_LOCATION : As result, device will send device location as >> latitude and longitude as well as human readable format of device location >> such as street, state, zip, country. >> >> Device info is stored in two database tables, One table is for all known >> and common information of any device such as device name, cpu usage, memory >> usage at any given time. And we have introduced a another database table >> which will can be used store uncommon data or device type specific data >> such as temperature, IMEI, IMSI etc... as key value fields. >> Location will be stored in a separate table and device application list >> will be stored in a separate table. >> >> Common device info table consist of the following column names. >> >> - >> - DEVICE_MODEL >> - VENDOR >> - OS_VERSION >> - BATTERY_LEVEL >> - INTERNAL_TOTAL_MEMORY >> - INTERNAL_AVAILABLE_MEMORY >> - EXTERNAL_TOTAL_MEMORY >> - EXTERNAL_AVAILABLE_MEMORY >> - CONNECTION_TYPE >> - SSID >> - CPU_USAGE >> - TOTAL_RAM_MEMORY >> - AVAILABLE_RAM_MEMORY >> - PLUGGED_IN >> >> I have a doubt on whether the search can be made against on combined > attributes table and specific attributes of device types table?. eg : > temperature and CPU_USAGE. > Yes, It can be done with the current implementation. Let me explain the implementation. When a few search criterias are provided, some criterias can be searched directly from common details table and where some criterias should be searched from custom field table (stored as key value pairs). When we join these two tables on device id (device id is common to both tables), one record from common table will join with one record from custom tables. So there will be quite a lot of records joining with each other. But always one raw from common table with one raw from custom table. Due to this reason we are not able to provide a single search query which can search for all the criterias. Such as if some one provides two attributes from custom table to be searched and both those attributes are joined by "AND" operator. There will be no search results returning, because joined table has lot of records, but each record has only one raw from custom attributes table and one raw from common table, So each raw has only key value fair. But there are two key value pairs provided which are joined by "AND" operator. So there will be records returned. So to overcome above issue, when search criterias are provided, all the critereas related to common table and location tables are searched from a single query. But for the rest of the criterias from custom table are searched from separate queries. And the results from all the queries aggregated together to have a single list of devices considering their joining state (AND/OR). One thing missing from the current implementation which is searching on device type, We will try add this as an improvement to current implementation. > > Further IMO, some of the common attributes that are mentioned above can be > not common considering the context of device type authors and usage. There > could be a use case where the company who uses CDMF and all there device > types are always plugged in so wont have a common attribute called > PLUGGED_IN, BATTERY_LEVEL. However some use case would be differ(eg in > the case of EMM I see IMEI,IMSI.. etc are common attributes). > Good points. Yes it differs from use case to use case. So it is matters drawing line between what is common and not common. It is not easy to do in IoT world, there is no much attributes to be taken as common. But what we have thought is, we tried to come up with some common attributes which will satisfy many use cases. > So I was wondering whether is it feasible to provide the capability in > CDMF to mention common attributes through an extension and we can include > above common attributes as the default extension. > > I am not sure what do you mean by above statement. If I understood correctly, you mention about getting the common attributes through extensions. If we give an extension point to provide common attributes, that means they will have to provide the database scripts too. I am not sure that is a good solution. Please correct me if I have misunderstood you. > *Device Search (Advance Search) * >> >> Searching devices which meet certain condition plays a vital role as well >> as storing device information. Searching device means running a sql query >> and giving result back. We have added a way to define search queries which >> meets the searching criteria. We have provided two searching criterias, >> simple and a complex one. Simple one is based on the string based search >> where a certain string is matched in against all the properties of devices. >> For the advance search user have to supply the following information to do >> the search. >> >> Advance search consists of many searching criterias such as find devices >> which have cpu usage over 40% and memory usage over 30% in Colombo area. So >> this has 3 search criterias depends on cpu usage, memory usage and >> location. Criteria (condition) can be defined as follows. >> >> - State (AND/OR) : This refers to how each search criteria should >> connect with others >> - Key : Name of the column to search for (If Key matches one of >> above, search will happen on common device details table, If key does not >> matches with one of above search will happen on device property table, If >> key equals to "location" search will happen on device location table.) >> - Value : Define the value for the key provided. >> - Operator : This refers to how key and value should be combined. >> Operator can have =, !=, <=, <, >=, >. >> >> Just wondered whether we could use the DAS DAL feature for this, As I > remember, we can link any of our own tables and datasources and we can run > the Lucene query against it,which is similar to above mentioned grammer. > This is just an Idea not sure whether it is feasible. > I did a search on using Lucene for this feature, but I could not find a good way with Lucene to solve the above problem I mentioned regarding how different search criterias cannot be searched from a single query. I will do more research on this and will change accordingly. If Lucence can solve the above problem, it is just matter of changing few lines of code to cater it. And again thank you for valuable inputs. Thanks Geeth > > > Thanks, > Ayyoob >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
