On quinta-feira, 21 de julho de 2016 13:40:13 PDT Abhishek Sharma wrote: > Hi Thiago > > > > But think of this usecase: a client may want to download a firmware > > update. > > That's definitely not JSON. > > They should not rely on CoAP-HTTP Proxy.
Why not? > Generally the firmware would be in > 10's of MB's and proxy won't be supporting that much file size. Reason > being that we don't have any option of chunked transfer in CoAP. We have > blockwise but even for that, proxy need to know content-length before hand, > download entire data and then trigger blockwise transfer. Storing lets say > 50+MB in RAM for specific client is not a good design. Hence proxy would be > limiting max payload length to something around 1-2 MB which is enough to > cover most informational payloads and something like images / icons. Fair enough, that can be a dynamic limitation and the proxy can reply with failure. However, for the most constrained devices, the firmware will be less than 1 MB, so it fits your parameters. Therefore, I don't see why it couldn't use the proxy. > > I think there's value in converting, like you're proposing. But this > > should be a secondary and optional functionality. So please move it to a > > second commit on top of the first. The first commit must implement the > > proxy without conversion; the second adds the functionality of > > translation, which must be triggered by the OCF client device. > > Yes we will support different content-types. As I mentioned in my separate > mail, client will tell its supported formats as part of request for http > resource. If http server response format matches any of clients supported > formats, proxy will forward response as it is. And in case server response > is JSON and client don't support that, proxy will do automatic conversion. > That way both requirements will be met. I propose that you convert if and only if the client says that conversion is acceptable. There should be a field in the command to the proxy that initiates the resource retrieval whether conversion is acceptable. > > If you're arguing about what goes in the HTTP headers of the requests as > > well as of the reply, then indeed those should be controlled and > > accessible by the client. There should be a way for the client to specify > > what content types it supports, plus maybe some extra headers that the > > HTTP service may require. The reply from the server should be conveyed in > > the reply packet too. > > Yes it would be, but one thing I want to add that with this feature, > IoTivity will no longer be supporting only CBOR. While communicating with > proxy, IoTivity devices can send and receive different payload formats like > xml, json, images etc. I don't think we should do that. I propose to do it like I said and simply insert the foreign payload as a Byte Text property inside the CBOR payload. Supporting other content types/formats means you're doing a generic proxy, which you yourself excluded. > > Either way, another point is that your design will change considerably > > from > > the version without HTTP. I don't want to do the work of reviewing twice. > > So please implement HTTPS. > > It won't. Only thing that will change is cahttpparser file. > Whether we add libcurl or anything else, that's the only file that will > change. Ok, so do it now. HTTPS is not optional. > > I'm asking you to choose a library that implements HTTP and HTTPS, with > > either a working HTTP2 implementation or the indication that it will soon > > have one. > HTTP2 parsing is supported in current parser. Parsing, but not the actual connection. I'm asking that you plan ahead and figure out how to do HTTP2, even if you don't implement it now. > > Anyway, I am accepting the argument from further above that this is not a > > generic CoAP proxy. That means it's a OCF service. By immediate > > conclusion, > > the Proxy-URI header is completely unnecessary and I do not want to see it > > in the code or anywhere else. The URI being obtained should be in the OCF > > payload. > > I also don't want to see any further references to RFC 7252 or to an IETF > > draft about HTTP mapping. We're not doing that. > > I don't get your point to reinvent something that is already defined in > spec. Whenever a feature is defined in spec. like content-type, coap over > TCP adapter, blockwise transfer etc. we are following spec. why do you want > "NOT TO FOLLOW" spec in this particular scenario ? Because you said you're not going to follow them. You said it's an OCF resource, accepting CBOR payloads and returning CBOR payloads. Then we should use OCF CRUDN to initiate the requests and obtain responses, with payloads formatted according to OCF rules. That means we don't need to use Proxy-URI headers because that's not part of the OCF protocol. Or you do a generic proxy. > > Exactly. If you use libcurl, you won't have to. > > Using libcurl won't change anything except replacing current http parser and > removing dependency on TCP client code. The mapping and functionality would > still be as per specification. Ok. > > a) the API is limited and can be expanded to support your use-cases > > To support proxy as service, we will have to add proxy specific api's in RI. No, you don't. Just redesign according to what I said above: the proxy is an OCF resource and responds to CRUDN as expected. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
