Sorry it took so long to get back to you, I had a busy weekend!
The code snippet below seems like it would work just fine. Though, I DO
have 1 point:
Storing the Representations in a map like that is likely not going to
work well for you long-term. URI is not guaranteed to be a unique value
if you end up doing a 'get' on multiple resources. For example, you
could have 2 'light' resources that get discovered that are on different
servers such that they only differ by address! (Or worse, be discovered
2x by over different transports.
We've implemented functionality recently that should allow you to
identify OCResource objects via its 'uniqueidentifier' field, which is
guaranteed unique. Additionally, I would then likely use a std::bind(or
lambda) to associate that unique-identifier with the get request.
In your case as long as you safely escape from foundResource if cur_res
already IS something, you are perfectly safe. Just wanted to point out
a way to guarantee uniqueness :)
-Erich
On Sun, 2015-01-04 at 23:59 +0900, Junghyun Oh wrote:
> Hi Erich,
>
>
> I think your suggestion seems satisfies my needs.
> Here is the code snippet the I've wrote based on suggestion
> & please do correct me if I'm wrong..
>
>
>
>
> // Hosting Module..
>
>
> OCResource cur_res;
> std::map<string, OCRepresentation> HostingRes;
>
>
>
>
> foundResource(std::shared_ptr<OCResource> resource)
> {
> // check whether found resource is host-able resource...
> // if then...
> resource->get(QueryParam(), &onGet);
> cur_res = resource;
> }
>
>
> onGet(..., const OCRepresentation rep, ...)
> {
> // store resource representation internally...
> HostingRes[rep.getUri(), rep];
>
> // start observing on this resource.
> cur_res->observe(..,...,&onObserve);
>
> // then register resource as a virtual resource & discoverable
> // so that the other resource clients can discover & request on
> this resource..
> OCPlatform.registerResource(~~~~~~);
>
>
> }
>
>
> Let me do the test with your suggestion whether it's enough for us. :)
>
>
> Thank you.
> Jay.
>
> 2015-01-03 20:02 GMT+09:00 Keane, Erich <erich.keane at intel.com>:
> 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:iotivity-dev-bounces at lists.iotivity.org] 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:junghyun.oh at samsung.com]
> 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:iotivity-dev-bounces at lists.iotivity.org] 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
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>
>
>
