From ken.zangelin at fiware.org Mon May 27 11:25:00 2019 From: ken.zangelin at fiware.org (Ken Gunnar Zangelin) Date: Mon, 27 May 2019 11:25:00 +0200 Subject: [Fiware-ngsi-ld] 100% compatible orionld and scorpio brokers Message-ID: Hi all, hope you had a pleasant trip back home from Genoa. Background: JM Cantera, Martin, Parwinder and myself had a short meeting during the summit in Genoa to discuss details/problems of the two ngsi-ld brokers. In our short meeting we didn't really get to DECIDE anything except that we want our two ngsild brokers to be "black-box-compatible", and that I promised to send an e-mail with details on my implementation so that we can start discussions on how to be 100% compatible. 1. First of all, I proposed to Cantera a modification of the three contexts we have right now (I also spoke to Martin about this and got positive feedback from him as well): o https://forge.etsi.org/gitlab/NGSI-LD/NGSI-LD/raw/master/defaultContext/defaultContext.jsonld o https://forge.etsi.org/gitlab/NGSI-LD/NGSI-LD/raw/master/defaultContext/defaultContextVocab.jsonld o https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld My suggestion is to include the contents of 'defaultContextVocab.jsonld' inside the core context and remove the first two. Only the core context would remain and the key-value "@vocab": " http://example.org/ngsi-ld/default/" would be part of the core context. I think we all agree to this simplification but we never "shook hands" on it ... I know that there is an idea on changing the URIs and more about the contexts: https://forge.etsi.org/gitlab/NGSI-LD/NGSI-LD/issues/1 If this "simplification proposal" is accepted by everyone, the issue should take this into account. Let's not change anything at all until all is clear and described in "issue/1" or elsewhere. 2. Second, all responses must be "self-sufficient", meaning that the contexts in the request must be echoed back in the response. In the case of batch creation of entites that can get a bit complicated (if Accept: application/json). We need to decide how to attack this problem. We talked about it in Genoa but we didn't really find any solution, did we? 3. Third, we need a "context server" to maintain and serve contexts "invented by requests". E.g. a POST /ngsi-ld/entities request, creating an entity with an inline context (or any contexct that is not a single-string-URI) and with Accept: application/json. The response must carry the context in the Link header, which means the context needs to be created in the context server as only a single URI is allowed in the HTTP Link header. Perhaps it's not 100% necessary, but wouldn't it be nice if we could agree on a URI path for the contexts served by the context server? We have both implemented this "feature", I myself made it a new service inside my orionld broker, with the URI: /ngsi-ld/ex/v1/contexts/ (If the Entity-ID is a urn it's clear, if URL, I include the http://, as it's part of the Entity-ID) You guys I believe implemented a separate server, with context creation via files in the file-system. For retrieval of contexts, I think you use: /ngsi-ld/contexts/ Let's agree on a common uri path for retrieval. 4. In the nextcoming days I will compile a list of details (seeing orionld as a black box) for each of the requests that orionld currently implements, and we'll discuss on how to have both brokers behave in an identical way, seen from outside. More to come ... Best regards, /KZ -------------- next part -------------- An HTML attachment was scrubbed... URL: