Erich, If you fixed something independent when you were working on CBOR, I would ask you to push the separately. CBOR depends on length & buffer logic. It is ok to wait and submit them together.
Pat > -----Original Message----- > From: Keane, Erich > Sent: Friday, June 12, 2015 12:39 PM > To: Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org; jonc at osg.samsung.com; > jihwan.seo at samsung.com > Subject: Re: [dev] To add payload length in CAInfo_t for block-wise transfer. > > I actually have exactly this kind of patch already on my local machine as a > part > of the CBOR changes. I was giong to push them together (Convert > Connectivity to only deal in Binary, Convert RI/C++ to use CBOR instead of > JSON), but I can do that separately if you'd like. > > > On Fri, 2015-06-12 at 13:37 +0000, Lankswert, Patrick wrote: > > > -----Original Message----- > > > From: iotivity-dev-bounces at lists.iotivity.org > > > [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Jon A. > > > Cruz > > > Sent: Friday, June 12, 2015 1:36 AM > > > To: jihwan.seo at samsung.com; iotivity-dev at lists.iotivity.org > > > Subject: Re: [dev] To add payload length in CAInfo_t for block-wise > transfer. > > > > > > On 06/11/2015 07:30 PM, ??? wrote: > > > > Dear All > > > > > > > > Hi. > > > > > > > > To get payload length in CA Layer, > > > > > > > > the method related to strlen / strcpy is used like below. > > > > > > > > > > > > "size_t len = strlen(info.payload);" > > > > > > > > but, if NULL characteristic is included in the payload. > > > > CA can't get accurate length of the payload through these methods. > > > > > > > > so..I think upper layer have to express the payload length through > > > > below > > > change. > > > > > > > > typedef struct > > > > { > > > > > > > > CAMessageType_t type; > > > > uint16_t messageId; > > > > CATokent_t token; > > > > uint8_t tokenLength; > > > > CAHeaderOption_t *option; > > > > uint8_t numOptions; > > > > CAPayload_t payload; > > > > > > > > * size_t payloadLength; // new member of the structure* > > > > > > > > } CAInfo_t; > > > > > > > > but, we should discuss it much. > > > > > > > > since RI layer also have to consider adding RI API for payloadLength. > > > > > > > > if you have some opinion. > > > > > > > > please let me know. > > > > > > > > ps. I have registerd the JIRA - > > > > https://jira.iotivity.org/browse/IOT-561 > > > > > > > > > Conceptually much of the code at various layers had been confusing > > > c-strings for buffers. There are some significant differences and > > > you've hit upon some of them. > > > > > > This had been pointed out several times in code reviews, and should > > > have been followed-up on already. The JIRA ticket can help with that. > > > > Yes! I am not sure where this was introduced, but the payload is block of > arbitrary octets. It could be a jpeg, JSON, CBOR or other. The CoAP PDU has > length and buffer. The string functions should never been used or > introduced. > > > > I am not sure if it pre-dated the CA rewrite, but it should not have > > survived > it. I pointed it out in several CA reviews. > > > > Pat > > _______________________________________________ > > iotivity-dev mailing list > > iotivity-dev at lists.iotivity.org > > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
