Hi, I've fixed (and pushed) the server not responding status 400 when POST'ing invalid document. In attachement, a valid JSON file. Let's try to converge quickly on JSON rendering.... Cheers Jean Le vendredi 24 janvier 2014 à 18:17 +0100, Augusto Ciuffoletti a écrit :
Mmmmh, in fact, this is not what I expect as a resource definition. Looks like sort of a "kind" definition.
2014/1/24 Boris Parak <xparak@mail.muni.cz> On Fri, Jan 24, 2014 at 4:25 PM, Jean Parpaillon <jean.parpaillon@free.fr> wrote: > Hi Boris, > Ooops, my mistake: I confirm erocci parses resource instance in a > "resources" object, not "kinds". > On the other hand, in JSON spec draft (version from april 29th 2013), > "id" and "title" are not in the "attributes" object, but at the same > level as "kind". Has it changed ? > > To be honest, I don't have any preference, we just have to agree and let > say the first implementation wins :)
I'm actually not sure, Florian should be able to shed some light on this. I seem to remember a private discussion with him about occi.core attributes and how they are not actually that different from other attributes ... I know we decided to include UUID as 'occi.core.id' in attributes and as top-level 'id' to stay compatible. Otherwise, I prefer the all-in-one approach for attributes.
> To clarify, in the document I use, the rendering is: > { > "resources": [ > { > "kind": "http://schemas.ogf.org/occi/infrastructure#compute", > "id": "10c0d368-b096-4923-b21a-a9d026008d05", > "title": "ThisPC", > "attributes": { > "occi": { > "compute": { > "architecture": "x86", > "cores": 1, > "hostname": "pc001", > "memory": 5, > "speed": 4000, > "state": "inactive" > } > } > }, > "id": "10c0d368-b096-4923-b21a-a9d026008d05" > } > ] > } > > Jean
Boris
> Le vendredi 24 janvier 2014 à 16:18 +0100, Boris Parak a écrit : >> Hello Jean, Augusto, >> >> may I join your debate? :-) >> >> A compute instance should be rendered as a resource not a kind, e.g. >> >> { >> "resources": [ >> { >> "kind": "http://schemas.ogf.org/occi/infrastructure#compute", >> "attributes": { >> "occi": { >> "core": { >> "id": "10c0d368-b096-4923-b21a-a9d026008d05", >> "title": "ThisPC" >> }, >> "compute": { >> "architecture": "x86", >> "cores": 1, >> "hostname": "pc001", >> "memory": 5, >> "speed": 4000, >> "state": "inactive" >> } >> } >> }, >> "id": "10c0d368-b096-4923-b21a-a9d026008d05" >> } >> ] >> } >> >> (or in the attachment) >> >> > My implementation is: >> > - both POST'ing and PUT'ing resources do not need id >> > - POST generates a uuid which is returned, prepending the category path. >> > For instance: >> > POST /compute/ -> /compute/xxxxxxxxx >> > - PUT, of course, does not need an id as it is the full path of the url. >> >> We are taking the same approach in rOCCI. >> >> Cheers, Boris >> >> On Fri, Jan 24, 2014 at 3:45 PM, Jean Parpaillon >> <jean.parpaillon@free.fr> wrote: >> > Hi Augusto, >> > There is a bug from erocci... and an error in your json file :) >> > >> > The JSON file not being correct, a 400 error should be returned instead >> > of 500. This is the bug. >> > >> > From the JSON file, there is a missing comma ',' after occi.core.title >> > value. Plus, after discussing on the maillist about JSON rendering, I've >> > implemented the JSON format as described in the spec (while I was using >> > the JSON format from C.One project which is different :/). I'm sorry for >> > that, but this is the price of using a draft representation :P >> > >> > Hence, the correct JSON file should be as attached. >> > I removed "id" from the attributes but I think the specification is not >> > clear: when POST'ing a resource, should the id be specified, then: >> > - if the id is specified and the resource exists, what should be the >> > answer, >> > - if the id is not specified, what is the server's behaviour ? >> > >> > My implementation is: >> > - both POST'ing and PUT'ing resources do not need id >> > - POST generates a uuid which is returned, prepending the category path. >> > For instance: >> > POST /compute/ -> /compute/xxxxxxxxx >> > - PUT, of course, does not need an id as it is the full path of the url. >> > >> > Cheers, >> > Jean >> > >> > Le vendredi 24 janvier 2014 à 15:21 +0100, Augusto Ciuffoletti a écrit : >> >> >> >> >> >> >> >> >> >> 2014/1/24 Jean Parpaillon <jean.parpaillon@free.fr> >> >> Could you send me the json file you've tried to post ? >> >> >> >> Looks like a bug as an bad input file should generate a clear >> >> parse_error. >> >> >> >> Jean >> >> >> >> >> >> Le vendredi 24 janvier 2014 à 12:22 +0100, Augusto Ciuffoletti >> >> a écrit : >> >> > I would like to be already at the step of POSTing a sensor, >> >> but what I >> >> > have done till now has been simply to upload the monitoring >> >> XSD in the >> >> > mnesia db, and see that it was there: too easy! And even >> >> easier now >> >> > as you tell me. >> >> > >> >> > But then I went back to understand the basics, so I tried to >> >> POST the >> >> > barebones "compute" I told you about. This was simply to >> >> understand >> >> > the processing, not to "debug" your code, and this has >> >> nothing to do >> >> > with monitoring. The problem I observed is related to the >> >> last >> >> > revision (checkedout circa one hour ago), and the reason why >> >> I ask you >> >> > is that I'd like to understand: probably I've missed >> >> something and >> >> > maybe you can help me... >> >> > >> >> > >> >> > >> >> > 2014/1/24 Jean Parpaillon <jean.parpaillon@free.fr> >> >> > Hi Augusto, >> >> > The code is changing really quickly. I suggest first >> >> you get >> >> > the latest >> >> > code. If you have a look at: >> >> > >> >> https://github.com/jeanparpaillon/erocci/wiki/Development-Status >> >> > you will see that links are (mostly) not handled yet >> >> (which >> >> > can be a big >> >> > problem for monitoring). >> >> > More inside: >> >> > >> >> > Le vendredi 24 janvier 2014 à 11:48 +0100, Augusto >> >> Ciuffoletti >> >> > a écrit : >> >> > > I've almost finished descending the code, and I >> >> have >> >> > successfully >> >> > > integrated the monitoring xsd (easy, but hello.erl >> >> code must >> >> > be >> >> > > retouched: loading an extension shouldn't need >> >> code >> >> > changes). >> >> > >> >> > >> >> > You're right. There has been a step forward in that >> >> direction >> >> > as >> >> > configuration is now given as a single structure to >> >> a >> >> > occi_config >> >> > module. This structure could be loaded direcly with >> >> > file:consult/1 >> >> > >> >> > > Then I tried to test POSTing the attached file >> >> with the >> >> > following cmd: >> >> > > >> >> > > curl -X POST -d@compute.json -H 'content-type: >> >> > application/occi+json' >> >> > > -v http://localhost:8080/compute/ >> >> > > >> >> > >> >> > >> >> > Ok. I suppose: >> >> > - either you declare links (which is not working >> >> yet :/) >> >> > - or you should pull the most recent code, as >> >> > >> >> > I will try to reproduce by the end of the day. >> >> > >> >> > Keep me informed, >> >> > Cheers, >> >> > Jean >> >> > >> >> > >> >> > > >> >> > > But the reply is a 500 (internal server error) and >> >> the >> >> > (partial) log >> >> > > is >> >> > > >> >> > > >> >> > > Error in process <0.264.0> with exit value: >> >> > > >> >> > >> >> {[{reason,undef},{mfa,{occi_http_collection,from_json,2}},{stacktrace,[{occi_parser,send_event,[{token,objBegin,undefined,1},ok,{parser,undefined,occi_scanner_json,{parser,<0.266.0>,occi_parser_json0,{parser,<0.265.0>,occi_parser_json... >> >> > > >> >> > > >> >> > > By the way, the GET /-/ works ok. Apparently the >> >> prototype >> >> > should be >> >> > > ready to accept the request. Any help? >> >> > > >> >> > > >> >> > > >> >> > > 2014/1/20 Augusto Ciuffoletti >> >> <augusto@di.unipi.it> >> >> > > Dear Jean and all, >> >> > > >> >> > > >> >> > > here I share a discussion initiated with >> >> Jean in >> >> > December, >> >> > > regarding the erocci client prototype. The >> >> purpose >> >> > (launched >> >> > > by Jean) is the implementation of a >> >> prototype client >> >> > using the >> >> > > Erlang/OTP framework, which is mainly used >> >> in >> >> > telecom >> >> > > applications and developed by Ericsson. >> >> > > >> >> > > >> >> > > The rationale is that OTP is strongly >> >> biased by >> >> > > distributed/concurrent environments, and >> >> allows >> >> > flexible and >> >> > > fast prototyping of cleanly defined >> >> solutions. So >> >> > that it is >> >> > > ideal for demo/testing/proofofconcept etc. >> >> In this >> >> > respect, >> >> > > the fact that it is a somewhat niche >> >> product is not >> >> > relevant. >> >> > > >> >> > > >> >> > > Jean has already implemented part of the >> >> client, and >> >> > during >> >> > > the last weeks I browsed his work: in the >> >> last email >> >> > I was >> >> > > questioning him about a "use case" that >> >> could help >> >> > the >> >> > > definition of the user interface. There >> >> are also >> >> > more >> >> > > technical issues, and my reply follows... >> >> > > >> >> > > >> >> > > >> >> > > 2014/1/19 Jean Parpaillon >> >> <jean.parpaillon@free.fr> >> >> > > Hi Augusto, >> >> > > >> >> > > Sorry for the late answer, but >> >> I've been >> >> > really busy >> >> > > these later days. >> >> > > As some other people looked >> >> interested in my >> >> > > implementation during the >> >> > > last meeting, I think it worth >> >> having this >> >> > discussion >> >> > > in public. I let >> >> > > you forward... >> >> > > >> >> > > Le vendredi 10 janvier 2014 à >> >> 18:25 +0100, >> >> > Augusto >> >> > > Ciuffoletti a écrit : >> >> > > > Just scratched the surface but >> >> now I start >> >> > having >> >> > > trivial questions: >> >> > > > what's the final purpose? Even >> >> if it is >> >> > just a proof >> >> > > of concept, you >> >> > > > certainly have an idea of what >> >> it is for. >> >> > > >> >> > > >> >> > > What a good question :) Without >> >> kidding, >> >> > what I >> >> > > understood from other >> >> > > implementations is they focus on >> >> > implementing a >> >> > > particular extension >> >> > > (ie, compute) with different >> >> backends and >> >> > connectors >> >> > > to existing APIs: >> >> > > OpenNebula, OpenStack, EC2, etc... >> >> I think >> >> > this is the >> >> > > case for rOCCI >> >> > > and I know it is for C.One. >> >> > > erocci objective is to provide a >> >> really >> >> > generic >> >> > > implementation of OCCI, >> >> > > not linked to any particular >> >> extension, as >> >> > to build >> >> > > either pure OCCI >> >> > > application (using OCCI as unique >> >> API) or as >> >> > API >> >> > > adapter, like for the >> >> > > others. >> >> > > >> >> > > Does it sound clearer ? >> >> > > >> >> > > >> >> > > >> >> > > Not completely. I would like to understand >> >> if this >> >> > engine >> >> > > ("OCCI implementation" for me is too >> >> vague) is on >> >> > the client >> >> > > side (i.e., embedded in a definite-purpose >> >> client), >> >> > or >> >> > > somewhere in the middle (switch) or on the >> >> server >> >> > side (OCCI >> >> > > adapter). In other words, what is the >> >> (meaning of >> >> > the) input >> >> > > and output. In my understanding the input >> >> is an XML >> >> > file that >> >> > > represents a cloud provision using the >> >> occi >> >> > paradigm. This is >> >> > > a static view, not very useful for the >> >> user, but >> >> > precious for >> >> > > testing/proofofconcept/development. The >> >> output >> >> > should be OCCI >> >> > > (using some or any rendering, even XML), >> >> and I >> >> > understand you >> >> > > are aiming at an XMPP architecture. But it >> >> is also >> >> > possible to >> >> > > have another kind of representation >> >> (graphical, >> >> > db?). If this >> >> > > is the framework, ok, now it is explicit. >> >> Otherwise, >> >> > please... >> >> > > >> >> > > >> >> > > > >> >> > > > >> >> > > > My impression is that it is part >> >> of the >> >> > cloud >> >> > > manager, in charge of >> >> > > > accepting cloud provisioning >> >> requests (in >> >> > json or >> >> > > xml), and turn them >> >> > > > into an internal representation >> >> (mnesia). >> >> > Does this >> >> > > match? In that >> >> > > > case a more significant demo >> >> should >> >> > include a demo >> >> > > xml, and the >> >> > > > possibility to submit a user >> >> defined xml, >> >> > ideally >> >> > > with a curl. The >> >> > > > result of the submission might >> >> be rendered >> >> > in some >> >> > > fancy way elsewhere >> >> > > > (graphic popup). >> >> > > > >> >> > > > About the code, there is >> >> probably a >> >> > redundant use of >> >> > > > "register_extension" that is >> >> defined in >> >> > occi module, >> >> > > but hello prefers >> >> > > > to use the one defined in >> >> > occi_category_mgr. >> >> > > >> >> > > >> >> > > You're right, I was thinking about >> >> making >> >> > occi module >> >> > > the only >> >> > > entry-point for the framework, but >> >> given the >> >> > changing >> >> > > internal APIs, it >> >> > > is not really effective as of >> >> today... >> >> > > >> >> > > > Nothing relevant. And I noticed >> >> that you >> >> > often use >> >> > > supervisors where a >> >> > > > worker might be sufficient >> >> (unless I >> >> > missed >> >> > > something). >> >> > > >> >> > > >> >> > > This is indeed my first real >> >> erlang >> >> > application. I >> >> > > would be really >> >> > > >> >> > > interested in knowing in what my >> >> use of >> >> > supervisor is >> >> > > not relevant. >> >> > > >> >> > > >> >> > > The "nothing relevant" refers to my >> >> previous point >> >> > (about the >> >> > > "register_extension") which is almost mere >> >> syntax. >> >> > > >> >> > > My point about the supervisor (instead of >> >> a simple >> >> > worker) is >> >> > > more significant. A supervisor is useful >> >> to control >> >> > a number >> >> > > of child processes: why do you use one if >> >> there are >> >> > none? >> >> > > Maybe you have something in mind that I >> >> have not >> >> > understood, >> >> > > or maybe you use a powerful tool first to >> >> refactor >> >> > to a >> >> > > simpler at a later stage in development. >> >> It is just >> >> > to >> >> > > know... >> >> > > >> >> > > >> >> > > >> >> > > > And also, why d'you use the xml >> >> parser >> >> > included in >> >> > > the exmpp, instead >> >> > > > of the more stable xmerl? >> >> > > >> >> > > >> >> > > My really next step after >> >> finishing one >> >> > complete >> >> > > column of the status >> >> > > wiki page (means a complete >> >> implementation >> >> > of at least >> >> > > one rendering) is >> >> > > to implement XMPP transport. >> >> That's why I've >> >> > been >> >> > > integrating exmpp from >> >> > > the beginning and then use its XML >> >> parser >> >> > which is >> >> > > also known to be >> >> > > quite performant... but this is >> >> not the >> >> > biggest >> >> > > argument for me. >> >> > > >> >> > > >> >> > > XMPP is a powerful protocol, the idea in >> >> itself is >> >> > exciting. >> >> > > But with the "restful" paradigm we have >> >> opted for a >> >> > rigorous >> >> > > "plain HTTP" approach. Is XMPP really >> >> useful for us? >> >> > And also: >> >> > > the server on the other side must >> >> understand your >> >> > XMPP? >> >> > > >> >> > > >> >> > > >> >> > > > >> >> > > > Next step is to explore the >> >> > category_mgr... >> >> > > > >> >> > > > >> >> > > > Bye! >> >> > > > >> >> > > >> >> > > Cheers, >> >> > > Jean >> >> > > >> >> > > >> >> > > >> >> > > Bye... >> >> > > >> >> > > >> >> > > Augusto >> >> > > >> >> > > >> >> > > PS: sorry for not (remotely) showing up at >> >> OGF: my >> >> > fault, I >> >> > > probably missed the e.mail with the room >> >> link. Any >> >> > news about >> >> > > the monitoring thing? >> >> > > >> >> > > >> >> > > > Augusto >> >> > > > >> >> > > > >> >> > > > >> >> > > > 2014/1/8 Jean Parpaillon >> >> > <jean.parpaillon@free.fr> >> >> > > > Hi Augusto, >> >> > > > Thank you very much for >> >> your >> >> > feedback. >> >> > > > I have updated the >> >> README file wrt >> >> > to your >> >> > > report. >> >> > > > >> >> > > > Let me know would you >> >> need some >> >> > > clarifications. >> >> > > > >> >> > > > >> >> > > > Cheers >> >> > > > Jean >> >> > > > >> >> > > > Le mercredi 08 janvier >> >> 2014 à >> >> > 12:36 +0100, >> >> > > Augusto Ciuffoletti >> >> > > > a écrit : >> >> > > > > Hi Jean, >> >> > > > > >> >> > > > > >> >> > > > > I'm starting today to >> >> explore >> >> > your work, >> >> > > from the >> >> > > > "start.sh", and >> >> > > > > proceed incrementally. >> >> I have >> >> > now an idea >> >> > > of how you have >> >> > > > modularized >> >> > > > > the whole (the >> >> erocci.png). Your >> >> > > suggestion for me (point 3) >> >> > > > is a >> >> > > > > reasonable exercise, >> >> when I'll >> >> > have a >> >> > > sufficiently clear >> >> > > > idea of the >> >> > > > > whole, so I'll do that >> >> if I'll >> >> > reach a >> >> > > reasonable >> >> > > > comprehension of the >> >> > > > > whole. My target is to >> >> make >> >> > monitoring >> >> > > operational, which is >> >> > > > somewhat >> >> > > > > straightforward since >> >> it is >> >> > "just" an >> >> > > extension.. >> >> > > > > >> >> > > > > ===report=== >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > Not really an issue, >> >> but I >> >> > haven't found >> >> > > the "issues" >> >> > > > file... >> >> > > > > >> >> > > > > >> >> > > > > Operationally, I >> >> checked out >> >> > erocci and I >> >> > > have tried a >> >> > > > "make" and a >> >> > > > > "make all" (not >> >> relevant, but >> >> > there is a >> >> > > "alll" in >> >> > > > the .PHONY) with an >> >> > > > > Ubuntu 13.10. On a not >> >> > completely fresh >> >> > > install I had to >> >> > > > "apt-get >> >> > > > > install" the following >> >> "dev" >> >> > packets to >> >> > > have a successful >> >> > > > make: >> >> > > > > >> >> > > > > >> >> > > > > libexpat1-dev >> >> > > > > >> >> > > > > libxml2-dev >> >> > > > > >> >> > > > > libssl-dev >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > Next I called the >> >> "start.sh" >> >> > whose final >> >> > > line was: >> >> > > > > >> >> > > > > 12:26:40.478 [info] >> >> Starting >> >> > HTTP listener >> >> > > [{port,8080}] >> >> > > > > >> >> > > > > >> >> > > > > ...and finally... >> >> > > > > >> >> > > > > curl -v -X GET >> >> > "http://localhost:8080/-/" >> >> > > > > * Adding handle: conn: >> >> 0x11e7d40 >> >> > > > > * Adding handle: send: >> >> 0 >> >> > > > > * Adding handle: recv: >> >> 0 >> >> > > > > * >> >> Curl_addHandleToPipeline: >> >> > length: 1 >> >> > > > > * - Conn 0 (0x11e7d40) >> >> > send_pipe: 1, >> >> > > recv_pipe: 0 >> >> > > > > * About to connect() >> >> to >> >> > localhost port >> >> > > 8080 (#0) >> >> > > > > * Trying >> >> 127.0.0.1... >> >> > > > > * Connected to >> >> localhost >> >> > (127.0.0.1) port >> >> > > 8080 (#0) >> >> > > > > > GET /-/ HTTP/1.1 >> >> > > > > > User-Agent: >> >> curl/7.32.0 >> >> > > > > > Host: localhost:8080 >> >> > > > > > Accept: */* >> >> > > > > > >> >> > > > > >> >> > > > > >> >> > > > > So, the toy is >> >> running, I have >> >> > to open >> >> > > it :-) >> >> > > > > >> >> > > > > >> >> > > > > Bye! >> >> > > > > >> >> > > > > >> >> > > > > === >> >> > > > >> >> > > >> >> > >> >> > /home/augusto/Scrivania/Erlang/erocci/trunk/deps/exmpp/c_src/exmpp_xml_expat.c:17:19: fatal error: expat.h: File o directory non esistente >> >> > > > > #include <expat.h> >> >> > > > > ^ >> >> > > > > compilation >> >> terminated. >> >> > > > > ERROR: compile failed >> >> while >> >> > > > > >> >> > > > >> >> > > >> >> > >> >> processing /home/augusto/Scrivania/Erlang/erocci/trunk/deps/exmpp: >> >> > > > > rebar_abort >> >> > > > > make: *** [all] Errore >> >> 1 >> >> > > > > === >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > Bye! >> >> > > > > >> >> > > > > >> >> > > > > Augusto >> >> > > > > >> >> > > > > >> >> > > > > 2014/1/6 Jean >> >> Parpaillon >> >> > > <jean.parpaillon@free.fr> >> >> > > > > Hi Augusto, >> >> > > > > As I told you, >> >> I have >> >> > tried to >> >> > > make some work on >> >> > > > erocci in >> >> > > > > order for you >> >> > > > > to be able to >> >> contribute >> >> > more >> >> > > quickly. >> >> > > > > >> >> > > > > 1/ A >> >> development status >> >> > page: >> >> > > > > >> >> > > > >> >> > > >> >> > >> >> https://github.com/jeanparpaillon/erocci/wiki/Development-Status >> >> > > > > Everything is >> >> not there. >> >> > For >> >> > > instance: resource >> >> > > > creation is ok >> >> > > > > in JSON >> >> > > > > (you can have >> >> a look at >> >> > file >> >> > > tests/json/valid7.json >> >> > > > for >> >> > > > > instance) but >> >> I >> >> > > > > don't manage >> >> yet links >> >> > nor mixins. >> >> > > > > 2/ I have open >> >> several >> >> > tickets on: >> >> > > > > >> >> > > >> >> > https://github.com/jeanparpaillon/erocci/issues >> >> > > > > 3/ A useful >> >> task for >> >> > occi wg >> >> > > should be to write a >> >> > > > little >> >> > > > > erocci >> >> > > > > application >> >> with a >> >> > simple config >> >> > > file. Basically, >> >> > > > the >> >> > > > > following is >> >> > > > > needed to have >> >> a working >> >> > OCCI >> >> > > server with erocci: >> >> > > > > - load one or >> >> several >> >> > OCCI >> >> > > extension files (XML) >> >> > > > > - map >> >> categories to URIs >> >> > > > > - setup the >> >> listener >> >> > (HTTP, as of >> >> > > today) >> >> > > > > - setup the >> >> backend >> >> > (mnesia, as of >> >> > > today) >> >> > > > > This is >> >> achieved with >> >> > erlang code >> >> > > in hello_occi.erl >> >> > > > file but >> >> > > > > all this >> >> > > > > could be >> >> described in a >> >> > > configuration file, either >> >> > > > an erlang >> >> > > > > configuration >> >> file or an >> >> > XML file. >> >> > > > > Would you be >> >> interested >> >> > in working >> >> > > on that ? >> >> > > > > >> >> > > > > You can >> >> already have an >> >> > example of >> >> > > erlang config >> >> > > > file looking >> >> > > > > at >> >> > > > > start.sh >> >> (which >> >> > generates a config >> >> > > file used by >> >> > > > hello_occi). >> >> > > > > You can have >> >> an idea on >> >> > how to use >> >> > > this file by >> >> > > > looking at >> >> > > > > >> >> > > >> >> http://www.erlang.org/doc/man/config.html >> >> > > > > >> >> > > > > This could be >> >> a erocci >> >> > application >> >> > > (like hello_occi) >> >> > > > to put in >> >> > > > > examples/ >> >> > > > > dir. >> >> > > > > >> >> > > > > What do you >> >> think of >> >> > it ? Take >> >> > > care: "Diving into >> >> > > > erlang is a >> >> > > > > one-way >> >> > > > > ticket" :) >> >> > > > > >> >> > > > >> >> > > >> >> > >> >> http://fr.slideshare.net/pavlobaron/erlang-is-a-one-way >> >> > > > > >> >> > > > > Best regards, >> >> > > > > Jean >> >> > > > > >> >> > > > > Le dimanche 29 >> >> décembre >> >> > 2013 à >> >> > > 16:24 +0100, Augusto >> >> > > > > Ciuffoletti a >> >> > > > > écrit : >> >> > > > > >> >> > > > > > Hi Jean, >> >> > > > > > >> >> > > > > > >> >> > > > > > I'm browsing >> >> you >> >> > erocci: nice >> >> > > work! >> >> > > > > > >> >> > > > > > >> >> > > > > > Curiosity: >> >> why XMPP in >> >> > > perspective? Ok, its >> >> > > > capabilities >> >> > > > > include plain >> >> > > > > > HTTP verbs, >> >> but isn't >> >> > it in >> >> > > contrast (i.e., >> >> > > > redundant) with >> >> > > > > a RESTful >> >> > > > > > approach? >> >> > > > > > >> >> > > > > > >> >> > > > > > I'm planning >> >> to >> >> > understand >> >> > > erocci and to include >> >> > > > the >> >> > > > > monitoring >> >> (which >> >> > > > > > seems rather >> >> > straightforward). >> >> > > If I can contribute >> >> > > > to it in >> >> > > > > any way, >> >> > > > > > just let me >> >> know: long >> >> > ago I was >> >> > > familiar with >> >> > > > Prolog, and >> >> > > > > Erlang >> >> > > > > > basics are >> >> the same. >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > Happy new >> >> year! >> >> > > > > > >> >> > > > > > -- >> >> > > > > > Augusto >> >> Ciuffoletti >> >> > > > > > Dipartimento >> >> di >> >> > Informatica >> >> > > > > > Università >> >> di Pisa >> >> > > > > > 56100 - Pisa >> >> (Italy) >> >> > > > > >> >> > > > > >> >> > > > > -- >> >> > > > > Jean >> >> Parpaillon >> >> > > > > Open Source >> >> Consultant >> >> > > > > Phone: +33 6 >> >> 30 10 92 86 >> >> > > > > im: >> >> > jean.parpaillon@gmail.com >> >> > > > > skype: >> >> jean.parpaillon >> >> > > > > linkedin: >> >> > > > >> >> > http://www.linkedin.com/in/jeanparpaillon/en >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > -- >> >> > > > > Augusto Ciuffoletti >> >> > > > > Dipartimento di >> >> Informatica >> >> > > > > Università di Pisa >> >> > > > > 56100 - Pisa (Italy) >> >> > > > >> >> > > > -- >> >> > > > Jean Parpaillon >> >> > > > Open Source Consultant >> >> > > > Phone: +33 6 30 10 92 86 >> >> > > > im: >> >> jean.parpaillon@gmail.com >> >> > > > skype: jean.parpaillon >> >> > > > linkedin: >> >> > > >> >> http://www.linkedin.com/in/jeanparpaillon/en >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > -- >> >> > > > Augusto Ciuffoletti >> >> > > > Dipartimento di Informatica >> >> > > > Università di Pisa >> >> > > > 56100 - Pisa (Italy) >> >> > > >> >> > > -- >> >> > > Jean Parpaillon >> >> > > Open Source Consultant >> >> > > Phone: +33 6 30 10 92 86 >> >> > > im: jean.parpaillon@gmail.com >> >> > > skype: jean.parpaillon >> >> > > linkedin: >> >> > http://www.linkedin.com/in/jeanparpaillon/en >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > -- >> >> > > Augusto Ciuffoletti >> >> > > Dipartimento di Informatica >> >> > > Università di Pisa >> >> > > 56100 - Pisa (Italy) >> >> > > >> >> > > >> >> > > >> >> > > -- >> >> > > Augusto Ciuffoletti >> >> > > Dipartimento di Informatica >> >> > > Università di Pisa >> >> > > 56100 - Pisa (Italy) >> >> > >> >> > -- >> >> > Jean Parpaillon >> >> > Open Source Consultant >> >> > Phone: +33 6 30 10 92 86 >> >> > im: jean.parpaillon@gmail.com >> >> > skype: jean.parpaillon >> >> > linkedin: >> >> http://www.linkedin.com/in/jeanparpaillon/en >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > Augusto Ciuffoletti >> >> > Dipartimento di Informatica >> >> > Università di Pisa >> >> > 56100 - Pisa (Italy) >> >> >> >> -- >> >> Jean Parpaillon >> >> Open Source Consultant >> >> Phone: +33 6 30 10 92 86 >> >> im: jean.parpaillon@gmail.com >> >> skype: jean.parpaillon >> >> linkedin: http://www.linkedin.com/in/jeanparpaillon/en >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Augusto Ciuffoletti >> >> Dipartimento di Informatica >> >> Università di Pisa >> >> 56100 - Pisa (Italy) >> > >> > -- >> > Jean Parpaillon >> > Open Source Consultant >> > Phone: +33 6 30 10 92 86 >> > im: jean.parpaillon@gmail.com >> > skype: jean.parpaillon >> > linkedin: http://www.linkedin.com/in/jeanparpaillon/en >> > >> > _______________________________________________ >> > occi-wg mailing list >> > occi-wg@ogf.org >> > https://www.ogf.org/mailman/listinfo/occi-wg >> > > > -- > Jean Parpaillon > Open Source Consultant > Phone: +33 6 30 10 92 86 > im: jean.parpaillon@gmail.com > skype: jean.parpaillon > linkedin: http://www.linkedin.com/in/jeanparpaillon/en >
-- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)
-- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en