DDS-Java 1.0b2 FTF Avatar
  1. OMG Issue

DDSJAVA — A Status is not an Event. An Event is not a Status, it notifies a status change

  • Key: DDSJAVA-32
  • Legacy Issue Number: 16541
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The org.omg.dds.core.status.Status class currently extends the java.util.EventObject.
    The issue I have with this is that a status and an event are to different concepts.
    A status represents a continuous value or set of values which are always defined,
    while an event represents and happening. For instance an event could be used to notify
    the change of status but not the status itself.

    [Resolution]
    That said the refactoring suggested is to re-organize the current status types
    so to clearly distinguish what is are statuses and what are the events. As such,
    all the status currently defined should remove reference to the source. Why?
    Because the statuses are retrieved from the source thus it is kind of silly to
    add back the source on the communication status.

    Let me give you an example ("dr" below is a DataReader):

    RequestedDeadlineMissedStatus s = dr.getRequestedDeadlineMissedStatus();

    // this give back the reader we already know, thus it is not real useful
    // information which should simply be removed.
    s.source())

    BTW the status types as well as the relative accessor methods should
    drop the trailing "Status" as it is not so informative.

    That said, we should add an event type associated to each status defined like this:

    class RequestedDeadlineMissedEvent

    { private RequestedDeadlineMissed status; private DataReader source; //... useful methods }

    The event type is the one that should be used as a parameter of the listener methods.

    Finally, it is worth noticing that the suggested refactoring will fix the
    DataAvailableStatus anomaly. This type currently defined as a status is actually
    an event and as such should be treated. So where is the anomaly, for this status
    there are no methods on the data reader and there is really no status information
    such as saying... Yes there are 15 new samples or something like this.

  • Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
  • Disposition: Resolved — DDS-Java 1.0b2
  • Disposition Summary:

    That said the refactoring suggested is to re-organize the current status types so to clearly distinguish what is are statuses and what are the events. As such, all the status currently defined should remove reference to the source. Why? Because the statuses are retrieved from the source thus it is kind of silly to add back the source on the communication status.
    Let me give you an example ("dr" below is a DataReader):
    RequestedDeadlineMissedStatus s = dr.getRequestedDeadlineMissedStatus();
    // this give back the reader we already know, thus it is not real useful
    // information which should simply be removed.
    s.source())
    BTW the status types as well as the relative accessor methods should drop the trailing "Status" as it is not so informative.
    That said, we should add an event type associated to each status defined like this:
    class RequestedDeadlineMissedEvent

    { private RequestedDeadlineMissed status; private DataReader source; //... useful methods }

    The event type is the one that should be used as a parameter of the listener methods.
    Finally, it is worth noticing that the suggested refactoring will fix the DataAvailableStatus anomaly. This type, currently defined as a status, is actually an event and as such should be treated. So where is the anomaly, for this status there are no methods on the data reader and there is really no status information such as saying... Yes there are 15 new samples or something like this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT