[omniORB] IDL semantics of event publication (including eventpayload)

[Tuser]

Tom,

Maybe I misunderstand what you try to do. I also clearly prefer compile time
type checking, as it always saves a lot of trouble later. But if you are
using the COS Notification 'as is' (?), then the IDL is given. There is
therefore no choice; you have to accept the limitations.

What we do is to 'wrap' the COS Notification interface. Simply create your
own provider/subscriber APIs with the IDL you have defined. In the APIs you
use the COS Notification service to issue/receive the events, and perform
the type checking and casting.

The API is linked in at the client side. It may seem weird to have an IDL
interface for an API, but remember that OmniOrb provides collocation, i.e.
the calls will be replaced by direct calls. Also means that the API can be
used from other implementation languages (but without collocation, i.e.
performance overhead).




Tom O'Reilly wrote:
> 
> Tuser and Renny, you are both correct of course. The event "payload"
> object is packed into a CORBA::Any by the publisher, and unpacked by the
> subscriber, and my application successfully does this. But I was hoping
> that I could use the navigation service IDL to express the publication
> operation and various payload types in a way that is enforced by my C++
> compiler. After all, software developers need to know what is inside the
> CORBA::Any payload. Documentation is one answer, but documentation can get
> out-of-date or programmers forget to include it. The IDL itself seems the
> ultimate documentation, since it is enforced at compile-time. 
> 
> I am thinking of something like this:
> 
> module auv {
> 
>   interface Navigation {
> 
>     struct Position {
>       float latitude;
>       float longitutde;
>       float altitude;
>     };
> 
>     // Synchronous operation to get vehicle position
>     void getPosition(out Position p);
> 
>     // A PositionEvent is published by the navigation service when it
> computes a new
>     // vehicle position. 
>     struct PositionEvent {
> 
>       // Subscribers should filter on this name
>       const string name = "PositionEvent";
> 
>       // Position object is the event payload
>       Position payload;
>     };
> 
>     // The servant must implement a method to publish PositionEvents to 
>     // COSNotification. NOTE: clients that want positional information
> will never 
>     // call this event! Instead they will subscribe to 
>     void publishPayload(in PositionEvent);
>   };
> };
> 
>  The problem I see with this approach is that potential client developers
> might be confused to see the publishPayload() operation; this operation
> should never be called by most clients. Rather, I define publishPayload()
> so that the service developer will be forced to implement publication of
> PositionEvents.
> 
> Is this a reasonable approach? Does anyone else worry about this kind of
> situation?
> 
> Thanks,
> Tom
> 
> 
> 
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> 
> 

-- 
View this message in context: http://www.nabble.com/IDL-semantics-of-event-publication-%28including-event-payload%29-tf4477937.html#a12792418
Sent from the OmniORB - User mailing list archive at Nabble.com.