[occi-wg] erocci
Boris Parak
xparak at mail.muni.cz
Fri Jan 24 10:56:28 EST 2014
On Fri, Jan 24, 2014 at 4:25 PM, Jean Parpaillon
<jean.parpaillon at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at gmail.com
>> > skype: jean.parpaillon
>> > linkedin: http://www.linkedin.com/in/jeanparpaillon/en
>> >
>> > _______________________________________________
>> > occi-wg mailing list
>> > occi-wg at 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 at gmail.com
> skype: jean.parpaillon
> linkedin: http://www.linkedin.com/in/jeanparpaillon/en
>
More information about the occi-wg
mailing list