Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of jdennis@redhat.com designates
 66.187.237.31 as permitted sender)
Message-ID: <4A5DFE6E.1010600@redhat.com>
Date: Wed, 15 Jul 2009 12:06:06 -0400
From: John Dennis <jdennis@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre
 Thunderbird/3.0b2
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: C++ API issues with ValueType et. al.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I recently attempted to write code which would serialize AMQP data into 
different formats and ran into a number of issues with the Qpid C++ API. 
Serialization code unlike application specific code does not have a 
prori knowledge of the format of the data, it must rely soley on what it 
finds in the data object presented (e.g. inspection).

1) Let start with a FieldTable which is a map whose values are 
FieldValue objects. The FieldTable object provides a number of accessors 
which return the value of a key as a specific type (e.g. getAsUInt64()). 
However if you're iterating through a FieldTable and have a reference to 
a FieldValue you run into problems. First you begin by calling getType() 
to learn the type of the value, but a FieldValue has a very limited set 
of type specific accessors (either on the FieldValue object or on the 
nested Data object which encapsulates the value). Here are a few quick 
observations/questions related to FieldValues:

* Shouldn't a FieldValue have an accessor method for each basic data type?

* There is a limited set of specialized template get() functions. But 
you have to know which ones are actually implemented or the generalized 
template throws a InvalidConversionException.

* It feels wrong from an API perspective to use templated functions 
rather than accessor methods, one has to know the right way to 
parameterize the template and which ones are implemented.

* If you know enough about how the code is implemented you can reach 
into the nested Data object in some circumstances, but from an API 
perspective this seems wrong, one is exposing too much implementation 
detail.

* You can't get basic types such as float or double, this requires one 
to return back to the FieldTable you're iterating through and use it's 
accessor method by performing a needless and somewhat expensive lookup 
by field name which internally just gets you back to the exact same 
FieldValue reference you already have in hand but can't use directly. 
Plus this won't work if and when lists are implemented (see below).

* There appears to be no direct support in either FieldTables nor 
FieldValues for unsigned integers whose width is less than 64 bits.


2) Version 10 of the AMQP protocol specifies two types of sequences, 
lists and arrays. Arrays are homogeneous, lists are heterogeneous.

* Qpid only implements arrays, lists appear to be unimplemented.

* Qpid's implementation of arrays appears to be incorrect, or at least 
inefficient. Arrays in Qpid are sequences of FieldValues, FieldValues 
embed the type information, but in an array the type is a property of 
the array, not it's individual elements. As a consequence one could end 
up with a element whose type does not match the type bound to the array 
(I didn't find any code which enforces the consistency of elements, but 
maybe I missed it).

* Shouldn't what Qpid 0.10 currently calls an Array actually be called a 
List and then add an implementation for Arrays?


-- 
John Dennis <jdennis@redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org