Plans for qpid::framing::FieldTable

[Ted Ross <tr...@redhat.com>]

Andrew,

I'm beginning to use field tables for my management work and I've found 
that the FieldTable interface (C++ broker) only has direct support for a 
couple of types (Integer, String, Timestamp, Table).  Do you have any 
plans to expand this set?  The above types are very generic whereas the 
types in the AMQP spec are very specific in terms of size and 
signedness.  What's the plan for supporting the larger set of available 
types in field tables?  I assume there's a 
consistent-naming-in-client-APIs issue here.

If I use the more generic interface (i.e. FixedWidthVariable template), 
I will need to embed AMQP type codes into my code which doesn't seem 
like a good idea from a maintainability standpoint.

-Ted

Re: Plans for qpid::framing::FieldTable

[Ted Ross <tr...@redhat.com>]

Actually, I'm only talking about simple types like uint8 and uint64.  As 
it is now, if I want to put a 64-bit number in a field table, I have to 
call it a "timestamp" and for an octet, I need to use 32 bits.  The 
latter isn't a huge problem because I'm not going to be sending a large 
quantity of data this way.  The former seems like a bit of a hack.

-Ted

Andrew Stitcher wrote:
> On Mon, 2007-11-12 at 14:47 -0500, Ted Ross wrote:
>   
>> Andrew,
>>
>> I'm beginning to use field tables for my management work and I've found 
>> that the FieldTable interface (C++ broker) only has direct support for a 
>> couple of types (Integer, String, Timestamp, Table).  Do you have any 
>> plans to expand this set?  The above types are very generic whereas the 
>> types in the AMQP spec are very specific in terms of size and 
>> signedness.  What's the plan for supporting the larger set of available 
>> types in field tables?  I assume there's a 
>> consistent-naming-in-client-APIs issue here.
>>     
>
> As it currently stands most of the 0-10 language bindings are similar.
> Do you have a need for different types specifically? If so which ones?
> Do you want to specify the signedness or length of your int? Or some
> other specific type.
>
> In general I think that the feeling is that there are too many very
> similar types (especially string ones) and the standard doesn't make it
> clear if some types are semantically the same as others. For example it
> would make sense to accept any string type irrespective of whether it
> was short or long (maybe you'd worry about iso8859-15 vs UTF though).
>
> Is this what you mean? Or are you interested in the remaining structured
> types? (Array and Sequence).
>
> Andrew
>
>
>   

Re: Plans for qpid::framing::FieldTable

[Andrew Stitcher <as...@redhat.com>]

On Mon, 2007-11-12 at 14:47 -0500, Ted Ross wrote:
> Andrew,
> 
> I'm beginning to use field tables for my management work and I've found 
> that the FieldTable interface (C++ broker) only has direct support for a 
> couple of types (Integer, String, Timestamp, Table).  Do you have any 
> plans to expand this set?  The above types are very generic whereas the 
> types in the AMQP spec are very specific in terms of size and 
> signedness.  What's the plan for supporting the larger set of available 
> types in field tables?  I assume there's a 
> consistent-naming-in-client-APIs issue here.

As it currently stands most of the 0-10 language bindings are similar.
Do you have a need for different types specifically? If so which ones?
Do you want to specify the signedness or length of your int? Or some
other specific type.

In general I think that the feeling is that there are too many very
similar types (especially string ones) and the standard doesn't make it
clear if some types are semantically the same as others. For example it
would make sense to accept any string type irrespective of whether it
was short or long (maybe you'd worry about iso8859-15 vs UTF though).

Is this what you mean? Or are you interested in the remaining structured
types? (Array and Sequence).

Andrew