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?. 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. > > *<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. 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). 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. *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. Thanks, Ayyoob
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
