[Fiware-cloud] some suggestions

Alex Glikson GLIKSON at il.ibm.com
Wed Mar 21 11:40:18 CET 2012


Lorenzo,

Thanks for your comments. Nice to know that someone is actually reading 
the documentation that we produce :-) See few comments inline below.

Further comments/suggestions are more than welcome!

Regards,
Alex




From:   Lorenzo Cantelmi <lorenzo.cantelmi at inria.fr>
To:     fiware-cloud at lists.fi-ware.eu, 
Cc:     Denis Caromel <denis.caromel at sophia.inria.fr>
Date:   21/03/2012 12:04 PM
Subject:        [Fiware-cloud] some suggestions
Sent by:        fiware-cloud-bounces at lists.fi-ware.eu



Hi all,

I make my own humble suggestions for wiki, that could be interesting:
in the Guiding Design Principles at this page  we should insert the 
reference to NIST Roadmap and similar; we have added links within 
individual paragraphs, but maybe should also add one when mentioning NIST 
for the first time.
in the FIware Extensions [here], at 2. point it is probably tpc, instead 
of tcp; TCP stands for Trusted Compute Pools (in this context).
in the Components subsection [here], at bullet Provisioning it is written 
that Provisioning is "responsible of deleting the actions that, it takes 
from the Action Queue", but you can not deduce it from the relative 
picture: basically a feedback arrow is missing; Fernando -- please, take a 
look if we need to update the diagram.
about Cloud Edge chapter, Cloud Proxy is basically a router evolved till 
application layer, a cloud consumer directly (via connection) will work 
with. So, assuming its hardware fails, consumer is stuck and can not work 
with deployed applications/services.  In the light of that, I guess we 
should specify that cloud proxy should assure redundancy HW (supply, hdd, 
etc). It is also the case for regular 'router' -- if it dies, you can not 
access the Internet at all. But I agree that specifying some design 
principles for Cloud Edge could be a good idea, including availability/ 
resiliency considerations. Pascal -- can you, please, take a look?
we use to speak about QoS, but, according with FG Cloud Technical Report 
Part 1 (III.2 Details on SLA measurement subsection, page 54 - 59 if we 
consider the offset), in such a new cloud environment we should speak of 
2QoS, that stands for Quality and Quantity of Service, to remark the 
evolution/innovation of the scenario we are offering. I don not know if 
this acronym is already in use, but sounds good for me. what do you think 
about? I'm not sure how much will we be able to invest in the direction 
within the current scope -- so I wouldn't necessarily want to create the 
perception that we plan major innovation in this direction. In any case, 
this is not a high priority for the first release. If it changes -- it 
would make sense to update the corresponding description (which will be 
updated towards the second release anyway).
Let me know your kind opinions.


Ciao,

Lorenzo_______________________________________________
Fiware-cloud mailing list
Fiware-cloud at lists.fi-ware.eu
http://lists.fi-ware.eu/listinfo/fiware-cloud

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20120321/da285981/attachment.html>


More information about the Old-Fiware-cloud mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy