Hello Maciej, Monday, August 17, 2009, 10:42:22 PM, you wrote:
>> 3. Use polling for the PostgreSQL server and asynchronous function >> calls for Oracle. MS> Interesting, but note what are the consequences. MS> Either there are two APIs exposed in the single class (session?) and MS> only one of them works (kind of a design problem) or there are separate MS> APIs exposed at the backend level. MS> The user would obtain the backend, downcast it to the actual type and MS> use the API that is specific to that particular backend. The Oracle MS> backend would have API for callbacks and the PostgreSQL backend would MS> have API for polling. MS> Both options look a bit dodgy, but the second option has the advantage MS> of design and implementation independence. How about introducing helper classes (friends of session) handling the notifications? There could be one implementation for asynchronous (Oracle) and one for synchronous/polling (PostgreSQL) notification events. This would leave the interfaces of all backends and the session untouched and would keep SOCI open for notification extensions of other backends. MS> The important question is whether the users (you!) would like to see MS> this feature and such a design approach - fragmenting the public API space. Like I said before: I am already using a patched SOCI with the PostgreSQL notification support. But I would prefer an official "clean" solution/interface. Rainer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
