[occi-wg] erocci
Augusto Ciuffoletti
augusto at di.unipi.it
Fri Jan 24 12:17:25 EST 2014
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 at mail.muni.cz>
> 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
> >
>
--
Augusto Ciuffoletti
Dipartimento di Informatica
Università di Pisa
56100 - Pisa (Italy)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20140124/24fc49d9/attachment-0001.html>
More information about the occi-wg
mailing list