[Fiware-ngsi] How to discus about NGSIv2 (it was Re: Standard operations support)

[Tobias Jacobs]

My vote is rather for 1 as I know quite some colleagues who are happy to receive the discussions in their inboxes bout probably would not interact with GH.

But then, if we go for the one-email-thread, everyone has to stick to the conventions. We could add a text to the beginning of the mail:
“
IN ORDER TO CONTRBUTE TO THE DISCUSSION, PLEASE ANSWER TO THIS EMAIL IN THE FOLLOWING FORMAT:

-        ANSWER INLINE TO THE DISCUSSION POINTS

-        DO NOT REMOVE ANY DISCUSSIONS (AND DO NOT REMOVE THIS TEXT EITHER)

-        HIGHLIGHT YOUR ANWERS SO THAT THEY CAN BE RECOGNIZED AS NEW. ALSO REMOVE THE HIGHLIGHTING FROM YOUR PREVIOUS ANSWERS.

-        SEPARATE NEW DISCUSSION POINTS BY A LINE OF “---------------------------------------“
“

Best
Tobias


From: fiware-ngsi-bounces at lists.fi-ware.org [mailto:fiware-ngsi-bounces at lists.fi-ware.org] On Behalf Of Fermín Galán Márquez
Sent: Montag, 13. Juli 2015 09:38
To: fiware-ngsi at lists.fi-ware.org
Subject: [Fiware-ngsi] How to discus about NGSIv2 (it was Re: Standard operations support)

Hi,

There are different possibility to carry out the discussions:

  1.  Only one email thread, all the discussions integrated in it separated by "-----", new content added email by email marked in a highlighted colour (i.e. red). This is the option we are using up to now and I think is effective: if you want to sync globally you can read the complete email, if you want to see only the new elements you can look for the highlighted texts.
  2.  Each discussion mapped in a GH issue. For me is ok. The main advantage regarding the previous one is that the historic of each discussion is stored in a less volatile medium (email is less volatile that GH issues) and that this discussion becomes public and out work transparent to external parties.
  3.  Each discussion mapped to a separated email thread. I think this mechanism doesn't have any advantage compared with 1 and having many email threads around may add confusion.

My vote is for 1 or 2.

Best regards,

------
Fermín

El 11/07/2015 a las 17:59, JOSE MANUEL CANTERA FONSECA escribió:
Dear colleagues,

Although I really appreciate your efforts to organize the discussion I’m totally lost in the thread.

I would suggest to open a new GH issue per discussion item and to comment over the issue. Another option is to have on email thread per issue … but I think we need to manage this properly in order to make the most of discussions and contributions.

Same comment applies to thread open by Tobias.

What do you think?

thanks

De: <fiware-ngsi-bounces at lists.fi-ware.org<mailto:fiware-ngsi-bounces at lists.fi-ware.org>> on behalf of "marc.capdevielle at orange.com<mailto:marc.capdevielle at orange.com>" <marc.capdevielle at orange.com<mailto:marc.capdevielle at orange.com>>
Fecha: viernes, 10 de julio de 2015, 14:27
Para: "fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>" <fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>>
Asunto: [Fiware-ngsi] Standard operations support

Hello,

To simplify the ongoing discussions, I propose we take each discussion point from the "[Fiware-ngsi] FIWARE NGSI API discussion points"  as a separate threads.

------


[TJ]   I think it would be good to keep the approach of having a set of basic operations (queryContextRequest etc.) with which in principle one can do everything, so that convenience operations only add convenience but not add functionality as compared to the basic operations?
[FGM2] In general, I agree. In fact, we plan to include standards operations also as part of the reference documentation. As I mention in my previous email: "The current draft at the above URL is focused on not-standard operations (sometime referred as "convenience operations") but at the end it will also include a specification for the standard operations (e.g. queryContext, updateContext, registerContext, etc.) based in the one we already have for the JSON encoding of that operations in the v1 API". However, there are some exceptions, eg: the convenience operation to get all the entity types ("GET /v2/types") in the sytesm doesn't have any counterpart in the standards operation family. But I understand that this is not a mayor problem.

[JH]  We definitively should keep the non-convenience operations (I wouldn't call them "standards" by the way, maybe we need to call them in another way).   However, I understand that we will implement some of the simplifications in the returned JSON structures, aren't we?   Leaving the developer the option to choose between self-contained (verbose :-) JSON structures and more simplified structures also would apply for these kind of operations.
[MC] As newcomers to the NGSI / Fiware ecosystem, me and some colleagues of mine have found very confusing that NGSI v1 exposes multiple ways of accessing the exact same information thought the standard and convenience operations. After a quite heated discussion with Tobias at the F2F meeting in Heidelberg, I now have a better understanding of the historic reasons that pushed the decision to have a subset of the NGSI standard operations duplicated as "convenience" REST endpoints... but I still think it was an error in the first place. Accepting that some developers need a more "convenient" way to access data is accepting that standard operation are not convenient (by not being RESTfull) and that design of the NGSI v1 APIs is flawed in some way.

The first thing to decide (and there was no consensus at the F2F meeting) is whether NGSI v2 is about :
- breaking compatibility with v1 allowing to change all the APIs,
- keeping compatibility with v1 and just adding missing functionalities (more a v1.1),
We need to decide on that first.

Then, *if* the NGSI v2 specification is about breaking compatibility with v1 and simplifying it using REST endpoints, it *may* be the right time to discuss if the standard operations need to be included in v2 and if we can move all the NGSI functionalities to "REST-like" endpoints. I say only "REST-like" as some NGSI concepts cannot be mapped fully to REST properly.

On another side, I don't have anything against keeping the standard operations for v2. But then, we should accept that the NGSI model is not adapted to the REST conventions and don't try to apply REST partially by duplicating endpoints.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição




_______________________________________________

Fiware-ngsi mailing list

Fiware-ngsi at lists.fi-ware.org<mailto:Fiware-ngsi at lists.fi-ware.org>

https://lists.fi-ware.org/listinfo/fiware-ngsi

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20150713/75937099/attachment.html>