Hi Alan, The changes to SubscriptionManager.cpp involved use of std::map::at(). That method is not included in RHEL 4's g++, and also not in Microsoft's lib. I changed it to use find() instead.
This raises a question that needs some clarification... The comments on the SubscriptionManager method say that if the entry is not found, an empty Subscription is returned. However, if at() doesn't find the key, it throws an exception. Find() creates an empty entry. Which way should this really be? Thanks, -Steve > -----Original Message----- > From: Alan Conway [mailto:[EMAIL PROTECTED] > Sent: Friday, October 24, 2008 10:00 PM > To: qpid-dev; Jonathan Robie; Lana Brindley > Subject: [c++] Changes to client API - AckPolicy is gone. > > > Apologies for doing this right at the code freeze but I only > realized 2 > days ago that the AckPolicy API was broken. The new API is only > incompatible for code that uses AckPolicy, it provides full > flexibility > for manual or automatic control over acquire and accept of subscribed > messages. It also makes Subscription a first-class object > which provides > a single logical place to collect future changes to subscriptions. > > Shout if you need help with documentation or code changes as > a result of > this. > > === > Client API change: Centralize access to subscription status, better > control of acquire/accept. > > client/SubscriptionSettings: struct aggregates flow control & > accept-acquire parameters for subscribe. > client/Subscription: represents active subscription. Query settings, > unacked messages, manual accept/acquire > client/AckPolicy: removed, functionality moved to Subscription and > SubscriptionSettings > client/SubscriptionManager: removed setters for subscription default, > use SubscriptionSettings. > > Issues addressed by the change: > - old SubscriptionManager use of bool for acceptMode > inverted wrt spec > values for accept mode. > - old AckPolicy was broken - not possible to access the instance > associated with an active subscription > - old AckPolicy did not provide a way to do manual acquire, only > accept. > - setting values on SubscriptionManager to apply to subsequent > subscriptions is awkward & error-prone, better to allow all > settings to > be supplied in subscribe() > - a subscription is a central concept in AMQP, it deserves to be a > class. Subscription and SubscriptionSettings provides a > single point of > update for future expansion of interactions with a a Subscription. > > > >
