Conversation with #occi
(03:58:38 PM) pkasprzak [~pete@i59F5E959.versanet.de] entered the room.
(04:00:04 PM) ffeldhaus: Hi
(04:00:13 PM) pkasprzak: hi
(04:00:30 PM) befreax: Hi all, todays topics are: * short Plugfest update * OCCI Rendering (headers,body,json) * Templates * Pending OCCI extensions
(04:01:01 PM) befreax: But first I wanna ask if everybody is okay with logging this session and distributing it later?
(04:01:29 PM) ffeldhaus: I'm ok with it
(04:01:30 PM) macredcape [~markcarl@64.134.149.164] entered the room.
(04:01:52 PM) pkasprzak: I'm also ok with it
(04:02:19 PM) befreax: great - @macredcape: are you okay with logging and distributing the log later?
(04:03:00 PM) macredcape: yes
(04:03:30 PM) befreax: perfect - okay let's get started with the first topic. I guess @ffeldhaus you can update us on plugfest?
(04:05:48 PM) ffeldhaus: the first day of the plugfest was nearly all devoted to CDMI testing of the NetApp CDMI Server, but I also managed to start a CDMI client library in Ruby which may be used in OpenNebula in the future.
(04:06:30 PM) ffeldhaus: yesterday the TU Dortmund OCCI implementation was tested and we had some debates on the future developments of CDMI and OCCI
(04:07:37 PM) ffeldhaus: during the afternoon sync up we discussed how OCCI could and should be more similar to CDMI from the REST structure
(04:08:05 PM) ffeldhaus: especially with regards to the rendering of attributes
(04:08:34 PM) befreax: I guess it get's time to work on that JSON rendering
(04:08:42 PM) ffeldhaus: there were also ideas to use CDMI to store OCCI objects and not just the storage used by OCCI
(04:09:48 PM) befreax: there where other fields of collab identified as well during the meeting in may - with regards to notification mechanism CDMI uses and which would be cool for OCCI
(04:09:49 PM) ffeldhaus: to sum up the Plugfest: the remote attendance is good, the OCCI attendance could be better, but we managed to have some nice discussions and we also had a few people from companies who were interested in using the standards for commercial cloud offerings
(04:10:11 PM) befreax: very cool! wanna do a blog post for the occi-wg website?
(04:10:23 PM) ffeldhaus: yes, maybe during OGF
(04:10:52 PM) befreax: cool ping - an email and I can add you as a contributor to our website
(04:11:09 PM) ffeldhaus: florian.feldhaus@tu-dortmund.de
(04:11:41 PM) befreax: So during the cloud plugfest was anything discussed with regards to the document Andy, Eugene and I put out with regards to interop of OCCI and CDMI?
(04:12:33 PM) ffeldhaus: no, not until now. I could bring this up today. Maybe a few more people could join the webchat here http://webconf.soaphub.org/conf/room/cloudplugfest so that we have more OCCI voices
(04:12:33 PM) lxndrp [~Adium@88.128.94.140] entered the room.
(04:12:49 PM) lxndrp: HI from 37000ft, guys.
(04:13:19 PM) befreax: I'll try to join that chat later
(04:13:27 PM) ffeldhaus: would be great
(04:14:17 PM) befreax: okay anything else on the plugfest topic?
(04:14:22 PM) ffeldhaus: the next plugfest will probably take place during september and the SNIA guys asked me, if we would like to do the plugfest thereafter in Europe
(04:14:38 PM) befreax: I would +1 that
(04:14:47 PM) ffeldhaus: me too ;-)
(04:14:47 PM) befreax: could help organize it if needed
(04:14:49 PM) lxndrp: Me too.
(04:15:10 PM) lxndrp: We can offer space for it; I have plenty rooms. Plus, Dortmund is close to DUS.
(04:15:26 PM) befreax: that'll be cool
(04:15:31 PM) ffeldhaus: Dortmund would be great
(04:15:35 PM) befreax: :-)
(04:15:50 PM) ffeldhaus: maybe during the lecture free period in March 2012?
(04:16:47 PM) lxndrp: Yup, sounds like a good idea.
(04:16:47 PM) ffeldhaus: we can discuss the details later, but I will announce that there is interest in doing the plugfest in europe
(04:16:55 PM) lxndrp: Yep.
(04:17:06 PM) befreax: nice!
(04:17:18 PM) pkasprzak: I second that :)
(04:17:42 PM) lxndrp: Ahm, can someone update me on today's agenda? I had some trouble logging in to FlyNet.
(04:18:00 PM) befreax: we just discuseed plugfest and will now move to renderings
(04:18:16 PM) befreax: So new topic is: OCCI renderings (headers, body and JSON)
(04:18:23 PM) befreax: To start with a quick note:
(04:18:39 PM) dizz1 [~dizz@84.203.114.155] entered the room.
(04:18:56 PM) befreax: The current OCCI rendering have an historic background and was something the group could agree on in short term. On the long term we should look into better options
(04:19:02 PM) befreax: Just that as a quick note to start with
(04:19:22 PM) befreax: In more general I think this discussion is surrounding the topic raised on the mailing list...
(04:19:25 PM) lxndrp: Hey dizz.
(04:19:46 PM) dizz1: howdee all, lxndrp :)
(04:20:00 PM) lxndrp: Yes, the current HTTP rendering makes some people unhappy.
(04:20:09 PM) ffeldhaus: The rendering is working for testing and currently I prefer to use a mix of text/occi for the request and text/plain for the response. But for larger requests and responses this doesn't work well
(04:21:29 PM) befreax: @feldhaus: what the specific problem iwht larger reponses?
(04:21:35 PM) befreax: +is
(04:21:47 PM) ffeldhaus: if you render them in the header, you may run out of http header space
(04:22:04 PM) befreax: I mean with text/plain and larger reponses?
(04:22:09 PM) ffeldhaus: and if you use text/plain, then you may have problems with encoding
(04:22:09 PM) lxndrp: I'd like to raise what Cyril stated: there should be a mix.
(04:22:26 PM) lxndrp: ffeldhaus: it's not only text/plain and encoding.
(04:22:37 PM) lxndrp: text/plain is rather meaningless for clients.
(04:22:53 PM) lxndrp: In addition, we basically waste the body.
(04:23:04 PM) lxndrp: FOr text/occi, i mean.
(04:23:18 PM) lxndrp: Plus, it's a pain to write custom parsers for the content of text/plain.
(04:23:21 PM) r2ad [Michael.Be@pool-173-79-137-131.washdc.fios.verizon.net] entered the room.
(04:23:26 PM) dizz1: text/plain makes sense with a priori knowledge - text/org.ogf.occi+plain would be better
(04:23:40 PM) dizz1: a priori knowledge sucks for standards
(04:23:57 PM) befreax: that's something for the errata and expericence doc
(04:24:04 PM) befreax: Do we have a tracker item for that?
(04:24:08 PM) lxndrp: Hm, dunno. Why don't we transport the gory details (payload) over some standard format?
(04:24:21 PM) dizz1: from what I've seen regarding cyrils objections the issue is related to media types in general
(04:24:36 PM) dizz1: we do - text :p
(04:24:39 PM) lxndrp: Yes, but I think that the problem lies deeper.
(04:24:46 PM) lxndrp: :P
(04:24:50 PM) dizz1: you still have to understand how to interpret it
(04:24:55 PM) dizz1: even if it was XML or JSON
(04:24:58 PM) lxndrp: A standard *structured* format.
(04:25:11 PM) lxndrp: Yes, I know. But both would be inline extensible.
(04:25:15 PM) dizz1: it is that right now - structured at least
(04:25:30 PM) lxndrp: Where for text, I always have to write some arcane parser.
(04:25:58 PM) dizz1: not if you use the ANTLR grammar :p
(04:26:06 PM) dizz1: yes and I agree with the bigger picture
(04:26:15 PM) dizz1: you have to write a parser for text
(04:26:19 PM) dizz1: and that's a PITA
(04:26:24 PM) dizz1: hence the grammar
(04:26:25 PM) lxndrp: dizzy dizz��� :o)
(04:26:30 PM) dizz1: :D
(04:26:52 PM) dizz1: JSON and XML is definitely easier given their wider tooling support
(04:27:04 PM) lxndrp: The idea would be to combine headers and some wider supported format.
(04:27:10 PM) dizz1: PS: lets not reignite the format wars of yester-years ;)
(04:27:33 PM) dizz1: sure that'd be welcome imo
(04:27:54 PM) r2ad: Are we talking about a rev2 to the spec or an extension? Or just changing th e spec to recommend an occi context type?
(04:28:12 PM) r2ad: just joined - sorry. Mike.
(04:28:16 PM) dizz1: but just remember the "headers" that OCCI uses is a means to transmit the "model state" and is not so much as meta-info to that state
(04:28:42 PM) dizz1: talking about content-type currently (i hope :))
(04:29:39 PM) lxndrp: r2ad: I think this is for v1.2
(04:30:13 PM) lxndrp: dizz1: agreed on formats. Should be easy to make json and xml, and let others do the rest.
(04:30:38 PM) lxndrp: dizz1: regarding headers, the important information is the Category and the Links.
(04:30:45 PM) macredcape: Signing off to head over to the tech center to start today's plugfest
(04:30:51 PM) macredcape left the room (quit: Quit: macredcape).
(04:31:38 PM) dizz1: those two can easily be rendered in the body given they're core to the model
(04:31:52 PM) dizz1: our "type system" is somewhat at odds with pure REST
(04:32:01 PM) dizz1: type info is relayed in REST via media types
(04:32:07 PM) dizz1: we don't do that strictly
(04:32:18 PM) dizz1: we indicate basic content/media type
(04:32:31 PM) dizz1: and then relay precise type info in the Category
(04:33:00 PM) lxndrp: I don't agree with calling RESTs media types a type system, Andy.
(04:33:03 PM) lxndrp: Not at all.
(04:33:20 PM) dizz1: the group considered having a set of media types a long time ago but that was downplayed as there was a fear of media type explosion
(04:33:24 PM) lxndrp: It's a way of indicating the representation or rendering of a resource.
(04:33:44 PM) dizz1: no it's not a type system - it's a means to relay type information
(04:33:50 PM) lxndrp: Not the *type* as in type system.
(04:33:58 PM) dizz1: so I'd agree with you
(04:34:21 PM) lxndrp: Insofar I don't see how the Category headers do collide with that.
(04:34:51 PM) lxndrp: What I am trying to say is that, given an OCCI resource with a certain category, it can be rendered through various media types.
(04:35:03 PM) lxndrp: And that's exactly what I'd like to leverage.
(04:35:49 PM) dizz1: so my thinking is that currently content-type tells you how to parse, Category tells you what class in your chosen language will use to represent the parsed content
(04:36:08 PM) dizz1: media types can certainly be used to do that also
(04:36:46 PM) lxndrp: I guess we are not saying anything different :-)
(04:36:49 PM) dizz1: however what media types cannot do is to tell you what that type consists of, how it's constructed
(04:36:52 PM) dizz1: nope :)
(04:37:07 PM) dizz1: and that's where we differ with the query interface
(04:37:52 PM) dizz1: REST allows for instance discovery and instantiation but it doesn't deal so much with type composition
(04:38:12 PM) dizz1: and afaik has no means to express it using HTTP
(04:38:18 PM) dizz1: that's where OCCI differs
(04:38:35 PM) dizz1: and why OCCI can allow for extension reasonably safely
(04:40:33 PM) ffeldhaus: so, how do we proceed?
(04:40:37 PM) dizz1: however that's all well and good but what's our current problem statement? as I think there might be differing views on this
(04:40:47 PM) lxndrp: But this extension we basically do via the category header.
(04:40:47 PM) dizz1: yep - good point ffeldhaus :)
(04:40:56 PM) lxndrp: Heh.
(04:41:06 PM) lxndrp: Let me try to formulate the problem:
(04:41:20 PM) ***dizz1 hat tip to lxndrp
(04:41:39 PM) lxndrp: 1. text/occi is flawed because of the header size limitation and the fact that we do not know what proxies do enroute.
(04:42:10 PM) lxndrp: 2. text/plain is flawed because it is not really text/plain, but in fact offers a structured format.
(04:42:46 PM) lxndrp: ad.1 we need to ensure that we keep the amount of information that OCCI lets travel over the headers as small as possible.
(04:43:01 PM) lxndrp: problematic headers in this context are:
(04:43:16 PM) lxndrp: a) X-OCCI-Attribute (highest danger)
(04:43:35 PM) lxndrp: b) Link (medium danger, for resources with *LOTS* of links)
(04:43:56 PM) lxndrp: c) Location and Category (lowest danger, size is known and controllable)
(04:44:15 PM) lxndrp: Can we agree so far?
(04:44:22 PM) ffeldhaus: yes
(04:44:24 PM) dizz1: agreed on 1., on 2. I say we need to define tightly the media type: basic media type is text but specialised to OCCI, agreed on 3
(04:44:40 PM) ffeldhaus: a and be must be outside of the header
(04:44:49 PM) lxndrp: There is no 3, dizz ;-)
(04:45:01 PM) dizz1: ok :) "ad.1"
(04:45:08 PM) lxndrp: ffeldhaus: I fully agree for a)
(04:45:33 PM) lxndrp: for b), I am not sure, since Link headers are something explicitly recommended by the IETF.
(04:45:59 PM) lxndrp: The question is whether we really have resources with extraordinarily large Link headers.
(04:46:00 PM) ffeldhaus: but maybe they were just having one link header in mind?
(04:46:19 PM) lxndrp: Not sure.
(04:47:46 PM) ffeldhaus: If you want to link to multiple storage instances, some network devices and some user defined resources, that'll be plenty of link headers. Now imagine a large base URI and you end up in the KB range for links
(04:48:50 PM) dizz1: then put the link representation in the body (i know that's not IETF compliant but���.)
(04:48:52 PM) lxndrp: Checking http://tools.ietf.org/html/rfc5988#section-3, you'll see that multiple headers are supposed to exist. Basically, this was designed to interlink document parts, with versioning.
(04:49:15 PM) r2ad: agree we need to address these. Would like to see body used.
(04:49:22 PM) dizz1: yes
(04:49:46 PM) dizz1: and lets not forget that in the current HTTP spec, the default place for rendering is in the body
(04:50:01 PM) lxndrp: Which would take us into the direction of Atom.
(04:50:21 PM) dizz1: if XML
(04:50:34 PM) lxndrp: I see the issue with the link header, but we lose many benefits if we move to body.
(04:50:41 PM) lxndrp: Like, efficient discovery.
(04:51:23 PM) lxndrp: So, let's see:
(04:51:26 PM) dizz1: discovery of links or..?
(04:51:57 PM) lxndrp: We agree that the Category and Location can stay in the header.
(04:52:19 PM) lxndrp: Discovery of a resource and its relations to other resources.
(04:52:31 PM) dizz1: so that's flawed imo
(04:52:39 PM) lxndrp: ?
(04:52:45 PM) lxndrp: Lost context now.
(04:53:02 PM) lxndrp: Can we first agree or disagree on the Category and Location stuff?
(04:53:58 PM) dizz1: ok - Location is a HTTP header so that's an easy one - done
(04:54:04 PM) r2ad: header sounds good for those.
(04:54:18 PM) lxndrp: Perfect.
(04:54:30 PM) dizz1: Category in the header to signal type, right?
(04:54:43 PM) lxndrp: Can we also agree on that the X-OCCI-Attribute must move to the body *in some way*?
(04:54:49 PM) ffeldhaus: Category works well in the header and it can be easily extracted by an implementation to understand what to do with the contents of the body
(04:54:53 PM) lxndrp: dizz1: yep.
(04:55:08 PM) lxndrp: ffeldhaus: Exactly. Thx!
(04:55:31 PM) r2ad: BTW: I recently read up on OpenGraph (http://ogp.me/) it puts all sorts of attrbutes in the body as meta properties.
(04:55:57 PM) r2ad: html rendering related.
(04:55:57 PM) dizz1: devils advocate: ok now someone that's a pure REST-head will say - that's (Category in header) redundant - you should _signal_ type using media types
(04:56:07 PM) ffeldhaus: CDMI does the same. Only a handful of attributes go to the header, the rest goes to the body
(04:56:42 PM) macredcape [~markcarl@63.247.204.212] entered the room.
(04:56:47 PM) dizz1: devils advocate: here's an example (of how it would be done as pure REST) from the once great SUN cloud API:
(04:56:50 PM) dizz1: POST /vdc/
(04:56:50 PM) dizz1: Host: xrgy.cloud.sun.com
(04:56:50 PM) dizz1: Authorization: Basic xxxxxxxxxxxxxxxxxxx
(04:56:50 PM) dizz1: Accept: application/vnd.com.sun.cloud.Status+json
(04:56:51 PM) dizz1: Content-Length: nnn
(04:56:54 PM) lxndrp: If we'd be amongst the pure REST eggheads, we wouldn't have actions ;-)
(04:57:13 PM) dizz1: see Tim Bray's post on that :p
(04:57:58 PM) lxndrp: Sorry guys, but what are we discussing now?
(04:58:03 PM) dizz1: in that example type is signaled via the standard header content-type
(04:58:10 PM) r2ad: links as actions....I like that.
(04:58:27 PM) dizz1: and that's where the REST eggheads will bitch about OCCI
(04:58:31 PM) lxndrp: Yes, but that's bullshit.
(04:58:38 PM) dizz1: :D
(04:58:50 PM) lxndrp: It would basically require everyone to come up with media types for everything.
(04:59:06 PM) lxndrp: Plus, I don't have the faintest idea of how inheritance is supposed to work with that.
(04:59:11 PM) dizz1: yes and that's the issue we wished to avoid over 1.5 years ago - media type explosion
(04:59:13 PM) ffeldhaus: we have Category headers and we should stick with them for now
(04:59:25 PM) lxndrp: ffeldhaus: +1
(04:59:33 PM) ffeldhaus: they're working ;-)
(04:59:37 PM) lxndrp: So let's get back for a second:
(05:00:00 PM) dizz1: ffeldhaus: yup, agreed however, always good to know ur enemy :p
(05:00:03 PM) lxndrp: Can we agree or disagree that X-OCCI-Attribute must move to the body, in whatever format?
(05:00:51 PM) ffeldhaus: I can agree on that
(05:01:02 PM) dizz1: ok by me (it's already there in the spec if using the cursed text/plain)
(05:01:12 PM) lxndrp: Ok.
(05:01:18 PM) dizz1: @befreax: any inputs?
(05:01:37 PM) lxndrp: He probably fell asleep.
(05:01:41 PM) lxndrp: :P
(05:01:44 PM) dizz1: lol
(05:01:49 PM) befreax: nothing new here for me :-) fine with me
(05:02:03 PM) befreax: had these discussion a loooong time ago
(05:02:04 PM) lxndrp: So the only leftover are Links, right?
(05:02:25 PM) lxndrp: At least three or for oooos missing, befreax
(05:02:56 PM) dizz1: sounds like
(05:02:58 PM) dizz1: ��� it
(05:03:16 PM) lxndrp: Ok, so what do we do about links?
(05:03:31 PM) lxndrp: benefit of link headers is discovery through HEAD.
(05:03:43 PM) dizz1: links are part of the resource (see the UML) so they should be as "close" to the attributes as is possible
(05:03:58 PM) lxndrp: drawback is that header size might grow large (although I'd like to see this proven).
(05:04:27 PM) dizz1: I've seen a collection of links for one resource easily in the +10KB range
(05:04:40 PM) dizz1: esp. if you use long resource ids
(05:04:40 PM) lxndrp: Then we probably don't have a choice.
(05:05:02 PM) ffeldhaus: ok. agreed on. Move the links to the body
(05:05:24 PM) lxndrp: We could leave this optional.
(05:05:28 PM) lxndrp: Either-or.
(05:05:42 PM) ffeldhaus: I don't think it's a good idea to make that optional
(05:05:51 PM) dizz1: so in the case of a resource instance, the body makes perfect sense
(05:06:00 PM) dizz1: if in the case of collections then it may differ
(05:06:00 PM) lxndrp: Something like "SHOULD render in the body, but MAY render in the header".
(05:06:09 PM) dizz1: esp. for pagination of collections
(05:06:26 PM) lxndrp: In the case of collections, the links are in the body, using text/uri-list.
(05:06:49 PM) dizz1: no they're X-OCCI-Location afaik
(05:07:05 PM) lxndrp: Huh?
(05:07:15 PM) lxndrp: What the hell am I implementing here then?
(05:07:15 PM) dizz1: soz (thinking text/plain)
(05:07:16 PM) lxndrp: ARGH.
(05:07:43 PM) dizz1: they're just link _values_ in the case of text/uri-list
(05:07:51 PM) dizz1: not a link entity however
(05:07:53 PM) lxndrp: Ah.
(05:08:01 PM) lxndrp: Yes, ok then everything fine here.
(05:08:32 PM) dizz1: well regarding collections there might be more discussion needed there
(05:08:48 PM) dizz1: but for now all is well
(05:09:08 PM) ffeldhaus: ok. How are we handling the body then?
(05:09:40 PM) lxndrp: I would suggest that we describe two generic body renderings, one XML and one JSON.
(05:10:19 PM) dizz1: ralf has JSON working afaik so can contrib there
(05:10:32 PM) lxndrp: personally I would prefer XHTML/RDFa, but tooling support is not nearly as good.
(05:11:24 PM) dizz1: likewise however there's debate in the RDFa, microformats etc world
(05:11:41 PM) lxndrp: debate?
(05:11:44 PM) ffeldhaus: we should have a standard rendering which will be supported by all servers
(05:12:18 PM) lxndrp: I would say that servers should support either XML or JSON, at the very elast.
(05:12:39 PM) ffeldhaus: then clients need to support XML and JSON to be on the safe side
(05:12:45 PM) lxndrp: Yes.
(05:13:14 PM) dizz1: clients should not be forced to support both, that's madness
(05:13:23 PM) lxndrp: But writing a client library for both is easier than convincing JSON people from XML.
(05:13:26 PM) dizz1: they can use content negotiation
(05:13:49 PM) lxndrp: ho would that help?
(05:14:07 PM) dizz1: "do you support JSON for OCCI?"
(05:14:23 PM) dizz1: server: "yes" client: "wonderful"
(05:14:35 PM) dizz1: "do you support XML for OCCI?"
(05:15:02 PM) dizz1: server: "no" client:"doh!" programmer:"I should of RTFM and used a better library"
(05:16:19 PM) lxndrp: Ah, well. How is this done? Accept-Headers?
(05:17:32 PM) dizz1: ya
(05:17:37 PM) ffeldhaus: ok. We will figure out the content negotiation during implementation. To get started with JSON, is there a description or example on how to do the JSON rendering?
(05:18:08 PM) lxndrp: I guess only Ralf has one.
(05:18:29 PM) lxndrp: Doing the XML one is rather trivial.
(05:18:51 PM) dizz1: I think I might have some examples (will have a look now...)
(05:18:55 PM) dizz1: JSON that is
(05:20:17 PM) ffeldhaus: could you send them to me?
(05:20:29 PM) dizz1: will do if I find them
(05:20:33 PM) ffeldhaus: thanks
(05:20:47 PM) r2ad: Gary had an XML based server
(05:20:56 PM) ffeldhaus: would be good to come up with the JSON rendering in the near future
(05:20:57 PM) lxndrp: BTW, we are on for 80 mins now.
(05:21:10 PM) lxndrp: I can make a first shot on XML.
(05:21:57 PM) lxndrp: Shall we conclude now and reconvene?
(05:22:31 PM) ffeldhaus: are you attending OGF?
(05:22:41 PM) macredcape left the room (quit: Remote host closed the connection).
(05:22:51 PM) dizz1: ffeldhaus: I've an OCCI parser-JSON-generator, I'll send it on and see about getting it up and running
(05:23:05 PM) ffeldhaus: great
(05:23:43 PM) dizz1: it takes text/plain and outputs JSON
(05:23:57 PM) dizz1: could also generate OVF also
(05:24:15 PM) lxndrp: ffeldhaus: Yes. Just being on the flight from DUS to ORD.
(05:24:21 PM) lxndrp: Will arrive with Philipp today.
(05:25:15 PM) dizz1: are there other topics people want to talk about?
(05:25:39 PM) lxndrp: dizz1: sounds great. We should however look that we can harmonize both renderings. If we do it right, one could just feed classes into a REST framework, and it would render everything nicely (think JAXB for Java)...
(05:25:47 PM) lxndrp: not from my side.
(05:26:36 PM) dizz1: FYI: OCCI was talked about briefly at the EMEA OpenStack conference and as a standardised API it was received well
(05:26:45 PM) ffeldhaus: I would like to suggest that we meet for a small OCCI plugfest maybe in september to harmonize all the different implementations
(05:26:52 PM) lxndrp: nice!
(05:27:11 PM) lxndrp: ffeldhaus: I was writing an email just now proposing a F2F in Dortmund before OGF33.
(05:27:18 PM) ffeldhaus: there's also a short mentioning in Cloud Computing Standards on IEEE Computing now http://www.computer.org/portal/web/computingnow/0711/whatsnew/internetcomputing?src=cnhome-v1
(05:27:18 PM) lxndrp: Would that be ok for you?
(05:27:24 PM) dizz1: Also there'll be an article on OCCI, OVF and CDMI integration appearing up on infoq.com sometime soon
(05:27:47 PM) ffeldhaus: lxndrp: good idea
(05:28:32 PM) ffeldhaus: just as a short note, we will improve the CDMI and maybe the OCCI Wikipedia pages today as part of the plugfest
(05:29:16 PM) lxndrp: ffeldhaus: Good that you took care of it. I totally paged it out.
(05:32:33 PM) befreax: Quick question: @r2ad, @dizz1 are you guys fine when we share the log afterwards?
(05:33:47 PM) dizz1: I'm fine
(05:34:05 PM) dizz1: rather: fine with that
(05:34:23 PM) befreax: :-)
(05:36:13 PM) ffeldhaus: ok, I will leave now to the SNIA building. See you guys in SLC tonight!
(05:38:52 PM) befreax: okay that'll leave the other two topics for discussion on the list
(05:39:07 PM) befreax: those topics where extensions and templates
(05:39:28 PM) befreax: okay thanks for joining guys!
(05:39:36 PM) befreax: Have fun in the US and talk to you soon
(05:40:08 PM) dizz1: cheers all! :)
(05:40:49 PM) befreax: take care!