FWIW, CDMI cannot use the HTTP headers for all of it's metadata as there are configuration restrictions that sometimes limit the amount of HTTP metadata to around 4k or so. We currently spec the metadata as part of the body for this reason. -- mark Sam Johnston wrote:
On Wed, Oct 7, 2009 at 3:37 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
There is a new HTTP section to the OCCI document. This sections describes OCCI attributes as HTTP headers. This section must be removed from the document !!
THIS INFORMATION OR APPROACH A HAS NOT BEEN APPROVED OR AGREED UPON.
PLEASE SUBMIT IT AS A PROPOSAL.
Now this definitely was me... sfaict you're the only person here who has a problem with it and yet you haven't presented any case for the inclusion of metadata in-band along with formats over which we have no control (e.g. OVF).
Nor have you answered my concerns about OCCI representations conflicting with external representations like OVF, for example where an auto-scaling system bumps up the cores/speed/memory without touching the underlying resource.
Nor have you presented an alternative that does not involve overhauling the model in order to separate workloads from containers as I had originally proposed.
I'm sure we'll discuss this (again) on the call, but let's focus on the facts in terms of pros and cons. There are 3 options:
* Use a wrapper format like SOAP or Atom to capture the metadata * Overhaul the model to cater for different representations of the same resources showing different realities * Keep the data and metadata separate using existing HTTP fuctionality (headers).
Sam
------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- <http://www.sun.com> * Mark A. Carlson * Sr. Architect *Systems Group* Phone x69559 / 303-223-6139 Email Mark.Carlson@Sun.COM