Hi Jay- I thought about this more today, and believe that the existing OCRepresentation object ought to satisfy this condition, doesn?t it? The response object will allow you to set the OCRepresentation object, which contains all of the mapped items. In the first bolded line, you would just wish to copy the OCRepresentation object for yourself. In the second bolded line, you would just do pResponse->setRepresentation with your copy (or another modified copy). Given that as the middle-object, the only thing I see missing from your example is the string-indexer (to support rep[uri] = Blah). This is something that I can do as well I suspect, there will be a bit of templating that I have to figure out, but I think I can get that too. Would that satisfy this need? Thanks! Erich From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Keane, Erich Sent: Friday, January 02, 2015 11:14 AM To: junghyun.oh at samsung.com; iotivity-dev at lists.iotivity.org Cc: ???; ???; ???; ??? Subject: Re: [dev] [Question] Is there any alternative data model for the "AttributeMap" (Which is removed now..)
I can definitely see the use case here. My concern is definitely with the additional size but mostly exposing a boost::variant (and all the trouble that comes with that). In this case, the AttributeSet object would need to be able to properly hold a int, float, bool, vector, etc. I?ll think this through a bit more, perhaps I can come up with a structure to do this in a clean/wrapped way. Thanks, Erich From: ??? [mailto:[email protected]] Sent: Thursday, January 01, 2015 6:44 PM To: Keane, Erich; iotivity-dev at lists.iotivity.org Cc: ???; ???; ???; ??? Subject: Re: RE: [dev] [Question] Is there any alternative data model for the "AttributeMap" (Which is removed now..) Hi Erich, Thanks for you reply. I really do appreciate it. The "Key Collection" you mentioned down below seems like the one that we needed for implementing the "Remote Resource Hosting" feature. To host a remte resource, the hosting module(?) should be able to keep the recent attribute key-value data recieved from the original resource server & distribute them to the resource clients if they requests them(GET/PUT/POST/..OBSERVE, DELETE? not sure). However, it would be more nice if we could have "Instance of something that have all the attributes information(Key-Value pairs)" not the "Instance of each attributes". For example.. // Remote resource Hosting private: std::map<std::string, AttributeSet > mRemoteResAttrs; void onFoundResource(const OCRepresentation rep) { AttributeSet set = rep.getSetofAttributes(); mRemoteResAttrs[ rep.getUri() ] = set; // this is just a code snippet.. } // Distributing the attributes value of remote resource which is being hosted.. void entityHandler(OCResourceRequest request) { auto pResponse = std::make_shared<OC::ResourceResponse>(); pResponse->setRequestHandle(...); .... if( mRemoteResAttr.find(request.getResourceURI() ) pResponse->setAttributeSet(mRemoteResAttr[ request.getResourceURI() ] ); } I coded my idea & needs with code snippet described above( Method with bold ) When hosting the remote resource, basically the hoster doesn't need to know the all the keys of the resource attributes.(If it knows them it could do more things but no need for now) Of course, we need to consider the size & affect of the base lib. that this change will bring, but I will be appreciated if you consider my need. Your thought? Thank you. Jay. ------- Original Message ------- Sender : Keane, Erich<erich.keane at intel.com> Date : 2015-01-01 05:04 (GMT+09:00) Title : RE: [dev] [Question] Is there any alternative data model for the "AttributeMap" (Which is removed now..) Hi Jay- I wrote the new OCRepresentation, so I?m somewhat privy to the implementation decisions. The AttributeMap (based on in-line-documentation) was meant to be an internal representation from the start, and I believe exposing it was a way of unblocking people along the way. During the OCRepresentation re-write, the AttributeMap stopped making sense, since our internal storage mechanism became much different. Rather than being a string/string map, the data is now stored using a boost::variant, which we are tentative to expose due to its fluid nature and potential for replacement. Before I left for vacation, I was planning a way of exposing the OCRepresentation keys as a collection, which could then expose the values appropriately. However, I haven?t done so yet. I was going to propose something at the beginning of next week to allow this feature, as it has been requested by a few others before. My thought was to expose a ?Keys? collection object that would contain a list of the following, so that people could correctly unpack and use them in a orthogonal way: Key name (String) Key Type (Enum class) Key Value (exposed via a getValue method, or a getValueAsString(useful for when it isn?t a string!). The idea would result in code that looks something like this (I?m typing this directly in outlook, so please pardon my formatting/pseudo-code-ness): void IterateValues(const OCRepresentation& rep) { for(auto& attribute : rep) // Having OCRepresentation expose a begin() and end() mechanism would allow this to be used in a standard STL compliant manner { //convert Enum to String Value may be left as an exercise to the reader if I cannot come up with a great to_string mechanism cout<<?Attribute name: ?<<attribute.name()<<? is of type ?<<ConvertEnumToStringValue(attribute.type())<<? with value of ?<<attribute.valueAsString()<<endl; cout<<?Actual Value: ?; switch(attribute.type()) { case AttributeType::Int: cout << attribute.getValue<int>();break; case AttributeType::Boolean: cout <<attribute.getValue<bool>();break; // and so on. This becomes difficult in the array-versions for obvious reasons, but I will still consider nicer ways to do this. } } As this is still being mulled over, I?d love to hear any feedback you have on this use case! Thanks! -Erich From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ??? Sent: Tuesday, December 30, 2014 8:45 PM To: iotivity-dev at lists.iotivity.org Cc: ???; ???; ???; ??? Subject: [dev] [Question] Is there any alternative data model for the "AttributeMap" (Which is removed now..) Hi Vijay & Pat. :) First of all, congratulations on the Public open of IoTivity.org & thank you all for your hard work. :) I have a question to ask about the "Data model" used in the IoTivity Base api. Previously, there was an api in the "OCRepresentation" which returns the instance of "AttributeMap" data model which has key-value information of a resource so that the application can get the resource data from it(AttributeMap) However, this api (which returns the instance of "attributeMap") has removed & the only way to get the attribute value is to use "OCPresentaion::getValue("key") by inserting "key"name. Is there any way or plan to open an api to get the instance of "AttributeMap" from the Application side? NotificationManager which features is to host remote-resources (on HW constrained device) was not able to host any resources because of this situation. Of course this is not a urgent request, however, I will be appreciated if you let us the plan or a way to get the "instance of AttributeMap of found resource" from the IoTivity base. :) Thank you. Jay. Jung-hyun Oh. IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD Mobile +82-10-9890-6731 | Beyond your imagination, Always Jung-hyun Oh. IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD Mobile +82-10-9890-6731 | Beyond your imagination, Always [cid:image001.gif at 01D02701.7BF6B240] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=e6c8c890fe3919e27544560a75ab9d313be324210089c11474ccf6874637380dc1861242bde8ccd17624746697f9fe6e4bea3c1765014a1208cece8541bc14eacf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150103/ddc015d7/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150103/ddc015d7/attachment.gif>
