That is kind of what I figured. I this is the 3rd person or so to suggest converting CA to binary/with length though, so if someone is REALLY needing it ASAP, I can provide it.
On Fri, 2015-06-12 at 18:05 +0000, Lankswert, Patrick wrote: > 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 >
