Return-Path: 
 <deltacloud-dev-return-2957-apmail-incubator-deltacloud-dev-archive=incubator.apache.org@incubator.apache.org>
X-Original-To: apmail-incubator-deltacloud-dev-archive@minotaur.apache.org
Delivered-To: apmail-incubator-deltacloud-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id DAC3D76C9
	for <apmail-incubator-deltacloud-dev-archive@minotaur.apache.org>;
 Thu,  3 Nov 2011 17:04:35 +0000 (UTC)
Received: (qmail 11536 invoked by uid 500); 3 Nov 2011 17:04:35 -0000
Delivered-To: apmail-incubator-deltacloud-dev-archive@incubator.apache.org
Received: (qmail 11516 invoked by uid 500); 3 Nov 2011 17:04:35 -0000
Mailing-List: contact deltacloud-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:deltacloud-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:deltacloud-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:deltacloud-dev@incubator.apache.org>
List-Id: <deltacloud-dev.incubator.apache.org>
Reply-To: deltacloud-dev@incubator.apache.org
Delivered-To: mailing list deltacloud-dev@incubator.apache.org
Received: (qmail 11508 invoked by uid 99); 3 Nov 2011 17:04:35 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Nov 2011 17:04:35 +0000
X-ASF-Spam-Status: No, hits=-5.0 required=5.0
	tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of lutter@redhat.com designates
 209.132.183.28 as permitted sender)
Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Nov 2011 17:04:28 +0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
 (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA3H45JH002124
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 3 Nov 2011 13:04:06 -0400
Received: from [10.3.112.51] (ovpn-112-51.phx2.redhat.com [10.3.112.51])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 pA3H45CH017721;
	Thu, 3 Nov 2011 13:04:05 -0400
Subject: Re: Sketch of CIMI model layer
From: David Lutterkort <lutter@redhat.com>
To: deltacloud-dev@incubator.apache.org
Cc: Doug Davis <dug@us.ibm.com>
Date: Thu, 03 Nov 2011 10:04:04 -0700
In-Reply-To: 
 <OF16FC5575.A3A8B869-ON8725793D.00460240-8525793D.00470CB5@us.ibm.com>
References: <1320275294-16956-1-git-send-email-lutter@redhat.com>
	 <OF16FC5575.A3A8B869-ON8725793D.00460240-8525793D.00470CB5@us.ibm.com>
Organization: Red Hat Inc
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
Message-ID: <1320339845.13424.33.camel@melon.watzmann.net>
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Virus-Checked: Checked by ClamAV on apache.org

On Thu, 2011-11-03 at 08:56 -0400, Tong Li wrote:
> In my previous implementation, request with body are always in xml format,
> it was never in a HTML form post. The reason was that DMTF spec did not
> really care HTML. All forms of requests should be in theory the
> content-type of application/CIMI-<ResourceType>+xml or
> application/CIMI-<ResourceType>+json. When I implemented the client to
> produce the request, I did not add that header, because I was not sure if
> add that header will actually break Sinatra so it may not be able to
> determine if the request is actually for xml or json.

That's actually a very good point: these custom MIME types are a pain in
the neck. They break the default behavior of any
dispatch-by-content-type framework, and require some manual fiddling to
get it back on track.

In Deltacloud, we generate the response with the following (in Rails,
the code would look exactly the same):

        respond_to do |format|
          format.xml  { .. generate XML output .. }
          format.json { .. generate JSON output .. }
        end

With the custom MIME types in the Accept header, the above doesn't work
out of the box - we painstakingly have to teach the framework that
application/CIMI-Foo+xml is really application/xml, and
application/CIMI-Foo+json is application/json.

The purported gain of being able to dispatch on/know what is being asked
for is not there. To me the whole thing is a little bit like replacing
image/png with image/passport-pic+png, image/soccer-team+png,
image/kittens-in-a-pile+png, etc.

If there ever is a need for the client to select the representation of a
resource by type, this can be done through media type parameters, i.e.
the client could send

        Accept: application/xml;type=BriefMachine,application/xml;q=0.8;type=FullMachine

But I don't really see a need for that - there is only ever one CIMI
Type that comes back from a request, and I don't believe that the
flexibility of choosing between types will really help implementors.

David