Hi Rasika, + 1 for filter out required operations responses that the user needs to get the related analytics. IMO this will improve the UX even better than just allowing or disallowing all the operation whether the information is needed to the user or not. @Charitha, good suggestion on configurations.
Thanks and Best Regards, On Mon, Jan 22, 2018 at 1:37 PM, Rasika Perera <[email protected]> wrote: > Hi All, > > Please find inline comments. > > @Ruwan: > >> <AnalyticsOperationConfigurations> >> <PublishLocationResponse>true</PublishLocationResponse> >> <PublishOperationResponse>true</PublishOperationResponse> >> </AnalyticsOperationConfigurations> >> IMO, this wording makes a bit more sense. Also, let's make sure to >> include explanations as to what these params enable. > > Looks good to me. However; `Operation Analytics` too make sense to me when > we consider it as a term for analytics on top of device operations. > > @Imesh: Thanks for confirming the UX aspect of the new configuration. > > @Inosh: > >> I assume in the default configuration we will keep both these values to >> false since by default we would not need the publish info to DAS. Also, >> when you say publish operation response, does it mean we are publishing all >> operation info such as application list, device info and policy responses? >> If it's only device info, naming the config to PublishDeviceInfoResponse >> would make more sense IMO. > > Yes, be default it will be false. With the current implementation we only > publishers operation response. +1 let's change it to the > PublishDeviceInfoResponse. > > @Charitha > >> Also since it is useful to publish Operation response payloads to >> Analytics for further processing, shall we add that capability to the IoTS? >> If so we might need to introduce a way to filter out required operations >> which needs to send responses to the Analytics. So I would like to suggest >> to change above configuration as follows to accommodate that. > > +1 for the idea. Let's make the it to publish any operation response as > suggested. > > Best Regards, > ~Rasika > > On Mon, Jan 22, 2018 at 12:53 PM, Charitha Goonetilleke < > [email protected]> wrote: > >> Hi Rasika & all, >> >> BTW, with our current implementation we are publishing operation response >> of DeviceInfo if *PublishOperationResponse* is enabled. So shall we >> changed it as *PublishDeviceInfoResponse* ? Also since it is useful to >> publish Operation response payloads to Analytics for further processing, >> shall we add that capability to the IoTS? If so we might need to introduce >> a way to filter out required operations which needs to send responses to >> the Analytics. So I would like to suggest to change above configuration as >> follows to accommodate that. >> >> <AnalyticsOperationConfigurations> >> <PublishLocationResponse>true</PublishLocationResponse> >> <PublishDeviceInfoResponse>true</PublishDeviceInfoResponse> >> <PublishOperationResponse> >> <isEnabled>true</isEnabled> >> <operations> >> <operation>BATTERY_LEVEL</operation> >> <operation>CHECK_LOCK_STATUS</operation> >> </operations> >> </PublishOperationResponse> >> </AnalyticsOperationConfigurations> >> >> Also if we want to publish responses for all operations, we can set it as >> follows: >> >> >> <AnalyticsOperationConfigurations> >> <PublishLocationResponse>true</PublishLocationResponse> >> <PublishDeviceInfoResponse>true</PublishDeviceInfoResponse> >> <PublishOperationResponse> >> <isEnabled>true</isEnabled> >> <operations> >> <operation>*</operation> >> </operations> >> </PublishOperationResponse> >> </AnalyticsOperationConfigurations> >> >> In order to received operation responses, we also need to have Event >> receiver and event stream in Analytics side. >> >> WDYT? >> >> Thanks & Regards, >> /charithag >> >> >> On Mon, Jan 22, 2018 at 12:46 PM, Inosh Perera <[email protected]> wrote: >> >>> Hi Rasika, >>> >>> +1, >>> I assume in the default configuration we will keep both these values to >>> false since by default we would not need the publish info to DAS. Also, >>> when you say publish operation response, does it mean we are publishing all >>> operation info such as application list, device info and policy responses? >>> If it's only device info, naming the config to PublishDeviceInfoResponse >>> would make more sense IMO. >>> >>> Regards, >>> Inosh >>> >>> On Mon, Jan 22, 2018 at 12:36 PM, Rasika Perera <[email protected]> >>> wrote: >>> >>>> Hi All, >>>> >>>> In IoT Server v3.1.0 geo location services is enabled with the >>>> following configuration; >>>> >>>> <GeoLocationConfiguration> >>>> <isEnabled>true</isEnabled> >>>> <PublishLocationOperationResponse>true</PublishLocatio >>>> nOperationResponse> >>>> </GeoLocationConfiguration> >>>> >>>> ​With the new feature developments; In latest IoT Server(master >>>> branch); now we also allow publishing device-info responses through the >>>> same configuration. >>>> >>>> <OperationAnalyticsConfiguration> >>>> <isEnabled>true</isEnabled> >>>> <PublishOperationResponse>true</PublishOperationResponse> >>>> </OperationAnalyticsConfiguration> >>>> >>>> However; there might be use cases for enabling *geo location services* >>>> *without* >>>> *publishing all the device-info* into IoT-Analytics server. Hence, As >>>> per the discussion with Charitha; I am planning to change the above >>>> configuration as below; >>>> >>>> <OperationAnalyticsConfiguration> >>>> <PublishLocationResponse>true</PublishLocationResponse> >>>> <PublishOperationResponse>true</PublishOperationResponse> >>>> </OperationAnalyticsConfiguration> >>>> >>>> WDYT? Appreciate your comments and ideas. >>>> >>>> Best Regards, >>>> ~Rasika >>>> >>>> -- >>>> With Regards, >>>> >>>> *Rasika Perera* >>>> Senior Software Engineer >>>> LinkedIn: http://lk.linkedin.com/in/rasika90 >>>> >>>> <http://wso2.com/signature> >>>> >>>> WSO2 Inc. www.wso2.com >>>> lean.enterprise.middleware >>>> >>> >>> >>> >>> -- >>> Inosh Perera >>> Senior Software Engineer, WSO2 Inc. >>> Tel: 077813 7285, 0785293686 >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> *Charitha Goonetilleke* >> Senior Software Engineer >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 77 751 3669 <%2B94777513669> >> Twitter:@CharithaWs <https://twitter.com/CharithaWs>, fb: charithag >> <https://www.facebook.com/charithag>, linkedin: charithag >> <http://www.linkedin.com/in/charithag> >> >> <http://wso2.com/signature> >> > > > > -- > With Regards, > > *Rasika Perera* > Senior Software Engineer > LinkedIn: http://lk.linkedin.com/in/rasika90 > > <http://wso2.com/signature> > > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Kamidu Sachith Punchihewa *Senior Software Engineer* WSO2, Inc. lean . enterprise . middleware Mobile : +94 (0) 770566749 <%2B94%20%280%29%20773%20451194> Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
