In C++, an ID is actually not necessary, since std::bind or a lambda is
meant to do exactly that! There is a pretty good example of it in the
fridge examples. Essentially, instead of &onGet in the example you can
call it with a function-object generated by std::bind (or a lambda) and
add parameter you wish. The great advantage over something in the API
is that you can exclude some parameters from your 'onGet' if you wish,
or add them arbitrarily (and even change order!).
So, an example below:
foundResource(std::shared_ptr resource)
{
using std::placeholders;
// function GenerateGetToken is written by you to do whatever you
// wish to get some sort of association.
auto requestInfo = GenerateGetToken();
// uses std::bind to add the token to the function callback. Also
ignores HeaderOptions and error code
resource->get(QueryParam(), std::bind(&onGet, requestInfo,
placeholders::_2);
auto requestInfo2 = GenerateGetToken();
// uses a lambda to do the same thing as the bind above
// (perhaps more clear to understand)
// In C++14, you can sprinkle a bunch more 'auto' around to
// make this even easier to type.
resource->get(QueryParam(),
[requestInfo2] // capture info, capture token by copy/move
(const HeaderOptions& headerOptions,
const OCRepresentation rep, const int ecode)
{
onGet(requstInfo2, rep);
});
}
onGet(GetToken tokenThing, const OCRepresentation rep)
{
// DO whatever you want, you know which request this is associated
// with since you have the tokenThing above!
}
On Tue, 2015-01-06 at 05:38 +0000, ??? wrote:
> Hi Erich,
>
>
>
> I appreciated for you feedback. The code snippet was to show the
> feasibilty of
>
> implementing the "Resource Hosting Feature" using existing APIs.
>
> However, yes you're right we need some extra logic to handle that kind
> of situation. :)
>
> As matter of fact, we already requested to provide an API or method
> from the base
>
> for that issue last year. (Need a way to map between request and its
> response in
>
> resource client side. Releated with Soft-Sensor Manager)
>
>
>
> Here is my thoughts that we could choose to handle this issue.
>
> * 1. ResourceRequest - ResourceResponse Match
> - We can match the request and its response if we could insert
> an ID into the request
> and get it back from the response
>
> * 2. Resource Server Host(or Server) ID Match
> - We can distinguish response messages, if we can get the
> unique ID from the source of
> response msg.
> - This is necessary if the device with resource server running
> has multiple connectivities
> (Both the IP-based & Non-IP-Based Connectivity) and
> if it changed the using connectivity type
> (from the IP-based to the Non-IP-Based or vice versa), then
> client should be able to identify the
> communicating resource server is the one that he was talking
> to...
> * 3. Mixture of 1 & 2
> - Since a client can send multiple requests to identical
> resource server, we need both.
>
> Since it is network programming, we cannot be sure when a client will
> receive the response from
>
> the server. The response for the early request can be arrived some
> time after recieving serveral
>
> response from the the other later requests.
>
>
>
> Again, thank you for pointing out the important requirement, and we
> will be appreciatd if the IoTivity-Base
>
> could support some APIs to handle this issue. :)
>
>
>
> Thank you.
>
> Jay.
>
>
>
>
>
> ------- Original Message -------
>
> Sender : Keane, Erich<erich.keane at intel.com>
>
> Date : 2015-01-06 02:47 (GMT+09:00)
>
> Title : Re: [dev] [Question] Is there any alternative data model for
> the "AttributeMap" (Which is removed now..)
>
>
>
> 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 HostingRes;
> >
> >
> >
> >
> > foundResource(std::shared_ptr 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 :
> > 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 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();
> >
> > 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
> >
> > 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: ?<> type ?<>
> value of ?<> cout<<?Actual Value: ?;
> > switch(attribute.type())
> > {
> > case AttributeType::Int: cout <<
> > attribute.getValue();break;
> > case AttributeType::Boolean: cout
> > <();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
> >
> >
> >
>
>
>
>
>
>
>
> Jung-hyun Oh.
>
> IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD
>
> Mobile +82-10-9890-6731 | Beyond your imagination, Always
>
>
>
>
>
>
>
>
>
