qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: C++ API issues with ValueType et. al.
Date Fri, 31 Jul 2009 17:10:51 GMT
Apologies for the delayed response, I had a few other issues that 
distracted my from this task...

John Dennis wrote:
> On 07/16/2009 07:03 AM, Gordon Sim wrote:
>> John,
>>
>> I agree with every point you make. The FieldTable and Array classes are
>> pretty horrible to use except for the simple cases and lack consistency
>> in design. They also expose boost which we are trying to move away
>> from[1] and tie the encoding details to the data structure[2] and
>> application visible API. In short, though we will obviously continue to
>> support it for existing users, I don't think that FieldTable in its
>> current form is really suitable as part of the exposed API in the long
>> term.
> 
> Thanks for the follow-up Gordon. I think you answered my high order bit 
> question. Do we fix what we have or do we re-implement it? 

I've gone back and forth on that question. I think we need to keep
FieldTable, and ideally not break existing applications or ABI.

What I've done so far is to define a new Variant type and have maps and 
lists of those. This is part of a proposed higher level api for 
messaging (see separate mail).

In terms of the implementation I've currently mapped these onto 
FieldValues for encode/decode so that I can use the existing 0-10 client 
code beneath the new api. Doing this I hit all the issues you discussed 
and so have modified FieldValue and FieldTable to address them (at least 
to a degree). I have also add a List type corresponding to the amqp0-10 
list.

> I was going 
> to offer to send a set of patches for the current implementation but in 
> a conversation with Ted Ross he cautioned patience because of the 
> possibility this area of the API might be reworked.

Attached is a patch that contains just the changes to FieldTable and 
FieldValue, plus the addition of the List class.

> It's good to know 
> there is a consensus the existing implementation needs some love and I 
> wasn't just out in left field somewhere due to misunderstandings.

No, it's definitely an area in need of some attention! My view is still 
that the best solution is an alternative api however as described I've 
ended up wanting to make some additions to the existing api as well (I 
believe these are all backwards compatible).

>> Some time ago the desirability of a higher level API for the c++ client
>> was discussed and I started some work on that. For the past couple of
>> months my attention has been diverted by other work but I hope to return
>> to it now. This API will include a variant type and a corresponding map
>> of these through which message properties would be accessed. The
>> intention is also to provide direct support for messages whose content
>> is an encoded form of a map or list. I still have some details to work
>> through of course, including how to avoid breaking the existing API
>> while avoiding expensive conversions.
> 
> At the moment I'm fine with waiting for the new implementation, I can 
> work around the issues from my end. I'll look forward to a cleaner 
> design when you have it ready. If you would like to bounce some design 
> ideas off me I'd be happy to provide feedback, or if there is a design 
> proposal on a wiki or some such you might want to provide a pointer to 
> that works as well.

That would be great! You can have a look at the framing namespace 
changes in the attached patch (unless anyone objects I'll probably check 
this part in shortly); for the alternative see the other mail on the 
messaging api.

--Gordon.

Mime
View raw message