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
[cid:image001.gif at 01D024F0.BA081FF0]
[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=a78cb8956f64d460738879c84ea4637f006ef5a530766747ed81201521b94ff84e60fcf6aeb61df594c3b6ddffd7613bcb238d00164b0be48eeb9bec5ad9c75d326bbdfb2ea96a2fcf878f9a26ce15a0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20141231/77c87890/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/20141231/77c87890/attachment.gif>
