22.6.2 Polling Model Signatures

   When the polling model is used, the client is returned a queriable poller when making the asynchronous invocation. The interface’s operations and attributes are mapped to implied-IDL operations with names prefixed by sendp_. If this implied-IDL operation name conflicts with existing operations on the interface or any of the interface’s base interfaces, ami_ strings are inserted between sendp_ and the original operation name until the implied-IDL operation name is unique.

   22.6.2.1 Implied-IDL for Operations

   The signature of the implied-IDL for a given IDL operation is:

• Each of the in and inout arguments in the order that they appeared in the operation’s declaration in IDL, all with a parameter attribute of in and with the type specifier and parameter name of the original argument.

• A type-specific Poller return type as described in Section 22.10, “Type-Specific Poller Mapping,? on page 22-26, followed by sendp_<opName> where opName is the name of the operation.

The async polling version takes the following parameters in order:

   • out arguments are ignored (i.e., are not part of the async signature).

   The implied-IDL operation signature has a context expression identical to the one from the original operation (if any is present).

   22.6.2.2 Implied-IDL for Attributes

   The signature of the implied-IDL for the polling model getter and setter operations corresponding to an interface’s attribute is as follows:

• Setter operations are only generated for attributes that are not defined readonly:

• A type-specific Poller return type as described in Section 22.10, “Type-Specific Poller Mapping,? on page 22-26, followed by the operation name, which to distinguish between the getter and setter operations for the attribute is given by either:

• sendp_get_<attributeName> for reading the attribute value, where attributeName is the name of the attribute, or • sendp_set_<attributeName> for setting the attribute value, where attributeName is the name of the attribute that is not defined readonly.

• Asynchronous implied-IDL operations for attributes have argument lists as follows:

• For the attribute’s generated get operation, there are no arguments. • For the attribute’s generated set operation, there is one argument, in <attrType> attr_<attributeName>, where attrType is the type of the attribute, and attributeName is the name of that attribute. The set operation is only generated for attributes that are not defined readonly.

   22.6.2.3 Example

   The following implied-IDL is generated from the interface definitions used in the running example:

   // AMI implied-IDL including polling operations// for original example IDL defined in Section 22.5 exception InvalidStock { string sym; };

   valuetype AMI_StockManagerPoller;

   interface StockManager { // Original operation Declarations attribute string stock_exchange_name; boolean add_stock(in string symbol, in double quote); void edit_stock(in string symbol, in double new_quote)

   raises(InvalidStock); void remove_stock(in string symbol, out double quote)

   raises(InvalidStock); boolean find_closest_symbol(inout string symbol); double get_quote(in string symbol) raises(InvalidStock);

   // Async Polling operation Declarations AMI_StockManagerPoller sendp_get_stock_exchange_name(); AMI_StockManagerPoller sendp_set_stock_exchange_name(

   in string attr_stock_exchange_name); AMI_StockManagerPoller sendp_add_stock(

   in string symbol, in double quote); AMI_StockManagerPoller sendp_edit_stock( in string symbol, in double new_quote); AMI_StockManagerPoller sendp_remove_stock( in string symbol); AMI_StockManagerPoller sendp_find_closest_symbol( in string symbol); AMI_StockManagerPoller sendp_get_quote( in string symbol); };