[Fiware-iot] Mandatory/Optional support for ConfMan GE

[t.elsaleh at surrey.ac.uk]

Hello Tobias, Fermin,

Thanks for the reply Tobias. It would good if Fermin can give his opinion on this as well.

Let's start with asserting what features/epics are mandatory and what are optional. As I mentioned, and what you (Tobias) confirmed is that non-functional features should be optional.

This takes us to the Epics/Features defined for the ConfMan by TID which are:


·         FIWARE.EPIC.ContextBroker.ParallelProcessingSupport,

o    I believe this is non-functional related epic therefore it should be optional.

·         FIWARE.EPIC.ContextBroker.MassiveDataSupport,

o   I believe this is non-functional related epic therefore it should be optional.

·         FIWARE.EPIC.ContextBroker.DataChapterGEsIntegration

·         I am not sure how D/C chapter here are a special case, since I guess they will also take the role of a NGSI-9 client. From the description, it hints to performance-related issues. But Fermin please correct me if I am wrong.

·         FIWARE.Feature.ContextBroker.AvailabilityContextSubscription&Notification,

o   This is a functional requirement and is therefore mandatory

·         FIWARE.Feature.ContextBroker.JSONSupport

o   Is this mandatory, since the main support is in XML?

·         FIWARE.Feature.ContextBroker.ConvenienceOperations,

o   This is a functional requirement and is therefore mandatory

This is my analysis of the epic/features. What is your take on this?

Best regards,
Tarek




From: Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: 18 April 2013 15:37
To: CARLOS RALLI UCENDO; Elsaleh T Mr (Electronic Eng)
Cc: FERMIN GALAN MARQUEZ; fiware-iot at lists.fi-ware.eu; Barnaghi P Dr (Electronic Eng)
Subject: RE: Full "architectural" support for (UoSurrey) ConfMan GE

Hi Tarek,

Your proposal sound pretty much complete operation-wise, and I would agree (but it is not me who decides that) that it is ok not to implement the nonfunctional features.
In summary, your GE implementation would be less tailored to performance, but instead have additional semantic discovery support.

I am also curious how semantic support will look like and how it is accessed with NGSI.
What I imagine is that registrations could be annotated with some metadata describing semantics, while discovery and subscribe-operations could use a specially defined scope type for making semantic queries.

Best regards
Tobias



From: CARLOS RALLI UCENDO [mailto:ralli at tid.es]
Sent: Mittwoch, 17. April 2013 19:10
To: t.elsaleh at surrey.ac.uk<mailto:t.elsaleh at surrey.ac.uk>
Cc: FERMIN GALAN MARQUEZ; Tobias Jacobs; fiware-iot at lists.fi-ware.eu<mailto:fiware-iot at lists.fi-ware.eu>; p.barnaghi at surrey.ac.uk<mailto:p.barnaghi at surrey.ac.uk>
Subject: Re: Full "architectural" support for (UoSurrey) ConfMan GE

Hi Tarek

Thanks for your mail.
I need to check carefully and discuss internally but looks much better than before!

Regarding docs, I'm almost sure it gets delayed too but I need to check agree this with the overall coordination. I'll come back to you on this matter ASAP.

BR

El 17/04/2013, a las 18:28, "t.elsaleh at surrey.ac.uk<mailto:t.elsaleh at surrey.ac.uk>" <t.elsaleh at surrey.ac.uk<mailto:t.elsaleh at surrey.ac.uk>> escribió:
Hello Carlos, Fermin, Tobias,

After discussing the matter internally, we (UoSurrey) will aim to provide our implementation for the GE by the end of Release 2.3, which I understand is end of June. This is due to the change in the IoT architecture last month in the F2F meeting, which has resulted in the removal of our original GE from the IoT architecture. We will aim to support the functions and interactions that are "architecturally" required for the ConfMan GE, meaning the ability to serve an NGSI-9 client that involves the following:


*         NGSI-9 standard operations

o   Register, discover, subscribe/notify

*         NGSI-9 convenience operations

o   Register, discover, subscribe/notify

*         NGSI-9 associations

*         NGSI-9 discovery restrictions (scopes)

*         NGSI-9 subscription restrictions

Fermin, Tobias, have I missed something?

I understand there are other features in the ConfMan GE that are concerned with internal performance, such as multithreading. These type of features we will not plan to support. I hope this still makes our GE compliant, from an architecture point-of-view.

Carlos, is the proposal OK? If so, can we confirm that UoSurrey will provide the GE implementation of ConfMan by end of June? This will mean that I will need to shift some of our features set in the Technical Roadmap to 2.3, as it doesn't make sense to provide these without the main functions of the ConfMan GE. Please can you also confirm whether the software documentation for our GE is still due on the 22nd of April or not? Because from what I understand that this will be delayed until June as well.


Best regards,
Tarek


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20130424/7ffbf7f5/attachment.html>