Issue 5767: Adding some filtering capabilities to the Lightweight Logging Service (lwlog-ftf) Source: THALES (Ms. Virginie Watine, virginie.watine@thalesgroup.com) Nature: Uncategorized Issue Severity: Summary: In order to add some possibilities to filter records, we would like methods that retrieve log records according to the fields defined in struct ProducerLogRecord (namely the level, producerId and producerName). That would consist in the three following methods to be added on the LogConsumer object. That point has been discussed during the Yokohama meeting with the supporters of this submission (in particular with Jeff Smith) and no difficulty to add these methods was foreseen. Resolution: see above Revised Text: In the document Lightweight Log Service Specification - OMG Final Adopted Specification ptc/03/04/01 UPDATE figure 2-1 with the new/changed operations REPLACE all occurrences of retrieve_by_id with retrieve_records REPLACE all occurrences of retrieveById with retrieveRecords with the exception of Sections 2.4.1 and 3.3.2.1 Section 2.4.1 CHANGE FROM: The getRecordIdFromTime operation returns the record Id of the first record in the Log with a time stamp that is greater than, or equal to, the time specified in the fromTime parameter. If the Log does not contain a record that meets the criteria provided, then the RecordId returned corresponds to the next record that will be recorded in the future. In this way, if this "future" recordId is passed into the retrieveById operation, an empty record will be returned unless records have been recorded since the time specified. Note that if the time specified in the fromTime parameter is in the future, there is no guarantee that the resulting records returned by the retrieveById operation will have a time stamp after the fromTime parameter if the returned recordId from this invocation of the getRecordIdFromTime operation is subsequently used as input to the retrieveById operation. TO: The getRecordIdFromTime operation returns the record Id of the first record in the Log with a time stamp that is greater than, or equal to, the time specified in the fromTime parameter. If the Log does not contain a record that meets the criteria provided, then the RecordId returned corresponds to the next record that will be recorded in the future. In this way, if this "future" recordId is passed to a retrieval operation, an empty record will be returned unless records have been recorded since the time specified. Note that if the time specified in the fromTime parameter is in the future, there is no guarantee that the resulting records returned by a retrieval operation will have a time stamp after the fromTime parameter if the returned recordId from this invocation of the getRecordIdFromTime operation is subsequently used as input to a retrieval operation. Section 3.3.2.1 CHANGE FROM: The get_record_id_from_time operation returns the record Id of the first record in the Log with a time stamp that is greater than, or equal to, the time specified in the fromTime parameter. If the Log does not contain a record that meets the criteria provided, then the RecordId returned corresponds to the next record that will be recorded in the future. In this way, if this "future" recordId is passed into the retrieveById operation, an empty record will be returned unless records have been recorded since the time specified. Note that if the time specified in the fromTime parameter is in the future, there is no guarantee that the resulting records returned by the retrieveById operation will have a time stamp after the fromTime parameter if the returned recordId from this invocation of the get_record_id_from_time operation is subsequently used as input to the retrieveById operation. TO: The get_record_id_from_time operation returns the record Id of the first record in the Log with a time stamp that is greater than, or equal to, the time specified in the fromTime parameter. If the Log does not contain a record that meets the criteria provided, then the RecordId returned corresponds to the next record that will be recorded in the future. In this way, if this "future" recordId is passed into a retrieval operation, an empty record will be returned unless records have been recorded since the time specified. Note that if the time specified in the fromTime parameter is in the future, there is no guarantee that the resulting records returned by a retrieval operation will have a time stamp after the fromTime parameter if the returned recordId from this invocation of the get_record_id_from_time operation is subsequently used as input to a retrieval operation. Add new sections to the LogConsumer Interface Operations starting with 2.4.3 2.4.3 retrieveRecordsByLevel Retrieves a specified number of records from the Log that correspond to the provided log levels. Synopsis + retrieveRecordsByLevel (inout currentId : RecordId, inout howMany : unsigned long, in valueList : LogLevelSequence) : LogRecordSequence Parameters and Return (ADD the Table with headings Parameter Type Description currentId RecordId The ID of the starting record howMany unsigned long The number of records to retrieve, will be updated to the number of records actually retrieved. valueList LogLevelSequence The sequence of log levels that will be sought <return> LogRecordSequence The sequence of retrieved records ) Exceptions This operation raises the InvalidParam exception if a supplied parameter is invalid. Description The retrieveRecordsByLevel operation returns a LogRecordSequence of records that correspond to the supplied LogLevels. Refer to section 2.2.2. The valueList parameter is composed of an undefined number of LogLevels. Candidate records for the LogRecordSequence begin with the record specified by the currentId parameter. The number of records in the LogRecordSequence returned by the retrieveRecordsByLevel operation is equal to the number of records specified by the howMany parameter, or the number of records available if the number of records specified by the howMany parameter cannot be met. The log will update howMany to indicate the number of records returned and will set currentId to either the id of the record following the last examined record or the next record that will be recorded in the future, if there are no further records available. If the record specified by currentId does not exist, but corresponds to the next record that will be recorded in the future, the retrieveRecordsByLevel operation returns an empty list of LogRecords, sets howMany to zero, and leaves the value of currentId unchanged. If the record specified by currentId does not exist and does not correspond to the next record that will be recorded in the future, or if the Log is empty, the retrieveRecordsByLevel operation returns an empty list of LogRecords, and sets both currentId and howMany to zero. Note that this operation does not guarantee a return of sequential records in Log and modifies the currentId value. Consequently, subsequent invocations of this operation with a different valueList or the other retrieval operations before reestablishing a record ID with the getRecordIdFromTime operation may result in the Log consumer not being able to obtain some of the records. 2.4.4 retrieveRecordsByProducerId Retrieves a specified number of records from the Log that correspond to the provided producer IDs. Synopsis + retrieveRecordsByProducerId (inout currentId : RecordId, inout howMany : unsigned long, in valueList : StringSequence) : LogRecordSequence Parameters and Return (ADD the Table with headings Parameter Type Description currentId RecordId The ID of the starting record howMany unsigned long The number of records to retrieve, will be updated to the number of records actually retrieved. valueList StringSequence The sequence of producer IDs that will be sought <return> LogRecordSequence The sequence of retrieved records ) Exceptions This operation raises the InvalidParam exception if a supplied parameter is invalid. Description The retrieveRecordsByProducerId operation returns a LogRecordSequence of records that correspond to the supplied producerIds. Refer to section 2.2.11. The valueList parameter is composed of an undefined number of producerIds. Candidate records for the LogRecordSequence begin with the record specified by the currentId parameter. The number of records in the LogRecordSequence returned by the retrieveRecordsByProducerId operation is equal to the number of records specified by the howMany parameter, or the number of records available if the number of records specified by the howMany parameter cannot be met. The log will update howMany to indicate the number of records returned and will set currentId to either the id of the record following the last examined record or the next record that will be recorded in the future, if there are no further records available. If the record specified by currentId does not exist, but corresponds to the next record that will be recorded in the future, the retrieveRecordsByProducerId operation returns an empty list of LogRecords, sets howMany to zero, and leaves the value of currentId unchanged. If the record specified by currentId does not exist and does not correspond to the next record that will be recorded in the future, or if the Log is empty, the retrieveRecordsByProducerId operation returns an empty list of LogRecords, and sets both currentId and howMany to zero. Note that this operation does not guarantee a return of sequential records in Log and modifies the currentId value. Consequently, subsequent invocations of this operation with a different valueList or the other retrieval operations before reestablishing a record ID with the getRecordIdFromTime operation may result in the Log consumer not being able to obtain some of the records. 2.4.5 retrieveRecordsByProducerName Retrieves a specified number of records from the Log that correspond to the provided producer names. Synopsis + retrieveRecordsByProducerName (inout currentId : RecordId, inout howMany : unsigned long, in valueList : StringSequence) : LogRecordSequence Parameters and Return (ADD the Table with headings Parameter Type Description currentId RecordId The ID of the starting record howMany unsigned long The number of records to retrieve, will be updated to the number of records actually retrieved. valueList StringSequence The sequence of producer names that will be sought <return> LogRecordSequence The sequence of retrieved records ) Exceptions This operation raises the InvalidParam exception if a supplied parameter is invalid. Description The retrieveRecordsByProducerName operation returns a LogRecordSequence of records that correspond to the supplied producerNames. Refer to section 2.2.11. The valueList parameter is composed of an undefined number of producerNames. Candidate records for the LogRecordSequence begin with the record specified by the currentId parameter. The number of records in the LogRecordSequence returned by the retrieveRecordsByProducerName operation is equal to the number of records specified by the howMany parameter, or the number of records available if the number of records specified by the howMany parameter cannot be met. The log will update howMany to indicate the number of records returned and will set currentId to either the id of the record following the last examined record or the next record that will be recorded in the future, if there are no further records available. If the record specified by currentId does not exist, but corresponds to the next record that will be recorded in the future, the retrieveRecordsByProducerName operation returns an empty list of LogRecords, sets howMany to zero, and leaves the value of currentId unchanged. If the record specified by currentId does not exist and does not correspond to the next record that will be recorded in the future, or if the Log is empty, the retrieveRecordsByProducerName operation returns an empty list of LogRecords, and sets both currentId and howMany to zero. Note that this operation does not guarantee a return of sequential records in Log and modifies the currentId value. Consequently, subsequent invocations of this operation with a different valueList or the other retrieval operations before reestablishing a record ID with the getRecordIdFromTime operation may result in the Log consumer not being able to obtain some of the records. Modify the LogConsumer Interface Section 3.3.2 interface LogConsumer : LogStatus { RecordId get_record_id_from_time ( in LogTime fromTime) raises(InvalidParam); LogRecordSequence retrieve_records ( inout RecordId currentId, inout unsigned long howMany) raises(InvalidParam); LogRecordSequence retrieve_records_by_level( inout RecordId currentId, inout unsigned long howMany, in LogLevelSequence valueList) raises(InvalidParam); LogRecordSequence retrieve_records_by_producer_id( inout RecordId currentId, inout unsigned long howMany, in StringSeq valueList) raises(InvalidParam); LogRecordSequence retrieve_records_by_producer_name( inout RecordId currentId, inout unsigned long howMany, in StringSeq valueList) raises(InvalidParam); }; Add new sections to the LogConsumer Interface PSM starting with 3.3.2.3 3.3.2.3 retrieve_records_by_level Retrieves a specified number of records from the Log that correspond to the provided log levels. Parameters and Return (ADD the Table with headings Parameter Type Description currentId RecordId The ID of the starting record. howMany unsigned long The number of records to retrieve. valueList LogLevelSequence The sequence of log levels that will be sought <return> LogRecordSequence The sequence of retrieved records ) Exceptions This operation raises the InvalidParam exception if a supplied parameter is invalid. Description The retrieve_records_by_level operation returns a LogRecordSequence of records that correspond to the supplied LogLevels. Candidate records for the LogRecordSequence begin with the record specified by the currentId parameter. The number of records in the LogRecordSequence returned by the retrieve_records_by_level operation is equal to the number of records specified by the howMany parameter, or the number of records available if the number of records specified by the howMany parameter cannot be met. The log will update howMany to indicate the number of records returned and will set currentId to either the id of the record following the last examined record or the next record that will be recorded in the future, if there are no further records available. If the record specified by currentId does not exist, but corresponds to the next record that will be recorded in the future, the retrieve_records_by_level operation returns an empty list of LogRecords, sets howMany to zero, and leaves the value of currentId unchanged. If the record specified by currentId does not exist and does not correspond to the next record that will be recorded in the future, or if the Log is empty, the retrieve_records_by_level operation returns an empty list of LogRecords, and sets both currentId and howMany to zero. Note that this operation does not guarantee a return of sequential records in Log and modifies the currentId value. Consequently, subsequent invocations of this operation with a different valueList or the other retrieval operations before reestablishing a record ID with the get_record_id_from_time operation may result in the Log consumer not being able to obtain some of the records. Mapping from the Platform Independent Model This IDL operation definition is the result of a one-to-one mapping from operation retrieveRecordsByLevel, defined in the UML class Log and made visible through interface LogConsumer in the PIM (See Section 2.4.3, "retrieveRecordsByLevel," on page 2-XXX). The spelling of the operation name has been changed to conform to the OMG IDL Style Guide. Difference to the Telecom Log Service This is a new operation, not available in the Telecom Log Service. It reflects the architectural and operational difference between the two services. 3.3.2.4 retrieve_records_by_producer_id Retrieves a specified number of records from the Log that correspond to the provided producer IDs. Parameters and Return (ADD the Table with headings Parameter Type Description currentId RecordId The ID of the starting record. howMany unsigned long The number of records to retrieve. valueList StringSeq The sequence of producer IDs that will be sought <return> LogRecordSequence The sequence of retrieved records ) Exceptions This operation raises the InvalidParam exception if a supplied parameter is invalid. Description The retrieve_records_by_producer_id operation returns a LogRecordSequence of records that correspond to the supplied producerIds. Candidate records for the LogRecordSequence begin with the record specified by the currentId parameter. The number of records in the LogRecordSequence returned by the retrieve_records_by_producer_id operation is equal to the number of records specified by the howMany parameter, or the number of records available if the number of records specified by the howMany parameter cannot be met. The log will update howMany to indicate the number of records returned and will set currentId to either the id of the record following the last examined record or the next record that will be recorded in the future, if there are no further records available. If the record specified by currentId does not exist, but corresponds to the next record that will be recorded in the future, the retrieve_records_by_producer_id operation returns an empty list of LogRecords, sets howMany to zero, and leaves the value of currentId unchanged. If the record specified by currentId does not exist and does not correspond to the next record that will be recorded in the future, or if the Log is empty, the retrieve_records_by_producer_id operation returns an empty list of LogRecords, and sets both currentId and howMany to zero. Note that this operation does not guarantee a return of sequential records in Log and modifies the currentId value. Consequently, subsequent invocations of this operation with a different valueList or the other retrieval operations before reestablishing a record ID with the get_record_id_from_time operation may result in the Log consumer not being able to obtain some of the records. Mapping from the Platform Independent Model This IDL operation definition is the result of a one-to-one mapping from operation retrieveRecordsByProducerId, defined in the UML class Log and made visible through interface LogConsumer in the PIM (See Section 2.4.4, "retrieveRecordsByProducerId," on page 2-XXX). The spelling of the operation name has been changed to conform to the OMG IDL Style Guide. Difference to the Telecom Log Service This is a new operation, not available in the Telecom Log Service. It reflects the architectural and operational difference between the two services. 3.3.2.5 retrieve_records_by_producer_name Retrieves a specified number of records from the Log that correspond to the provided producer names. Parameters and Return (ADD the Table with headings Parameter Type Description currentId RecordId The ID of the starting record. howMany unsigned long The number of records to retrieve. valueList StringSeq The sequence of producer names that will be sought <return> LogRecordSequence The sequence of retrieved records ) Exceptions This operation raises the InvalidParam exception if a supplied parameter is invalid. Description The retrieve_records_by_producer_name operation returns a LogRecordSequence of records that correspond to the supplied producerNames. Candidate records for the LogRecordSequence begin with the record specified by the currentId parameter. The number of records in the LogRecordSequence returned by the retrieve_records_by_producer_name operation is equal to the number of records specified by the howMany parameter, or the number of records available if the number of records specified by the howMany parameter cannot be met. The log will update howMany to indicate the number of records returned and will set currentId to either the id of the record following the last examined record or the next record that will be recorded in the future, if there are no further records available. If the record specified by currentId does not exist, but corresponds to the next record that will be recorded in the future, the retrieve_records_by_producer_name operation returns an empty list of LogRecords, sets howMany to zero, and leaves the value of currentId unchanged. If the record specified by currentId does not exist and does not correspond to the next record that will be recorded in the future, or if the Log is empty, the retrieve_records_by_producer_name operation returns an empty list of LogRecords, and sets both currentId and howMany to zero. Note that this operation does not guarantee a return of sequential records in Log and modifies the currentId value. Consequently, subsequent invocations of this operation with a different valueList or the other retrieval operations before reestablishing a record ID with the get_record_id_from_time operation may result in the Log consumer not being able to obtain some of the records. Mapping from the Platform Independent Model This IDL operation definition is the result of a one-to-one mapping from operation retrieveRecordsByProducerName, defined in the UML class Log and made visible through interface LogConsumer in the PIM (See Section 2.4.5, "retrieveRecordsByProducerName," on page 2-XXX). The spelling of the operation name has been changed to conform to the OMG IDL Style Guide. Difference to the Telecom Log Service This is a new operation, not available in the Telecom Log Service. It reflects the architectural and operational difference between the two services. Add new operations to the Complete Logging Service IDL Section 4 After the producer log sequence typedef typedef sequence<LogLevel> LogLevelSequence; typedef sequence<string> StringSeq; After the retrieve_by_id(records) operation LogRecordSequence retrieve_records_by_level( inout RecordId currentId, inout unsigned long howMany, in LogLevelSequence valueList) raises(InvalidParam); LogRecordSequence retrieve_records_by_producer_id( inout RecordId currentId, inout unsigned long howMany, in StringSeq valueList) raises(InvalidParam); LogRecordSequence retrieve_records_by_producer_name( inout RecordId currentId, inout unsigned long howMany, in StringSeq valueList) raises(InvalidParam); Actions taken: November 26, 2002: received issue November 6, 2003: closed issue Discussion: Resolution: Agreed to introduce filtering and modify the name of the retrieve by id operation to better align with the new operations End of Annotations:===== From: virginie.WATINE@fr.thalesgroup.com To: issues@omg.org Cc: lwlog-ftf@omg.org Subject: Adding some filtering capabilities to the Lightweight Logging Se rvice Date: Tue, 26 Nov 2002 14:26:57 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Dear all, In order to add some possibilities to filter records, we would like methods that retrieve log records according to the fields defined in struct ProducerLogRecord (namely the level, producerId and producerName). That would consist in the three following methods to be added on the LogConsumer object. That point has been discussed during the Yokohama meeting with the supporters of this submission (in particular with Jeff Smith) and no difficulty to add these methods was foreseen. Kind regards, -- Virginie Watine T H A L E S COM / SC2 1-5, Avenue Carnot 91883 MASSY Cedex Tel : +33 1 69 75 35 56 Fax : +33 1 69 75 31 79 mailto: virginie.watine@fr.thalesgroup.com ------------------------------------------ ==================================================================== Recommended change for OMG document : realtime/2002-06-07 - Lightweight Logging Service 1. Platform Independant Model: ------------------------------ (In the document this section will be located at 2.4.3, after page 22) 2.4.3 RetrieveRecordsByLevel Synopsis: RetrieveRecordsByLevel (in valueList: LogLevelSequence) : LogRecordSequence Exception : This operation raises the InvalidParam exception if the supplied parameter is invalid.. Description: This operation extracts all the records corresponding to the wanted levels. The unique parameter is composed of a list of an undefined number of LogLevels. (Note: Another possibility for the parameter would be a mask of the wanted levels. This would be less costly and would be easier if the different levels were specified in that sense (0X0001, 0X0002, 0X0004 etc.) ) (In the document this section will be located at 2.4.4, after page 22) 2.4. 4 retrieveRecordsByProducerId Synopsis: retrieveRecordsByProducerId ( in valueList: StringSequence) : LogRecordSequence Exception : This operation raises the InvalidParam exception if the supplied parameter is invalid.. Description: This operation extracts all the records corresponding to the wanted producerIds. The unique parameter is composed of a list of an undefined number of strings. (In the document this section will be located at 2.4.5, after page 22) 2.4.5 retrieveRecordsByProducerName Synopsis: retrieveRecordsByProducerName ( in valueList: StringSequence) : LogRecordSequence Exception : This operation raises the InvalidParam exception if the supplied parameter is invalid.. Description: This operation extracts all the records corresponding to the wanted producerNames. The unique parameter is composed of a list of an undefined number of strings. 2. Platform Specific Model - (IDL) ---------------------------------- interface LogConsumer : LogStatus { RecordId get_record_id_from_time ( in LogTime fromTime) raises(InvalidParam); LogRecordSequence retrieve_by_id ( inout RecordId currentId, inout unsigned long howMany) raises(InvalidParam); LogRecordSequence retrieve_records_by_level( in valueList LogLevelSequence) raises(InvalidParam); LogRecordSequence retrieve_records_by_producerId( in valueList LogLevelSequence) raises(InvalidParam); LogRecordSequence retrieve_records_by_producerId( in valueList StringSequence); raises(InvalidParam); LogRecordSequence Retrieve_records_by_producerName( in valueList StringSequence) raises(InvalidParam); }; ==================================================================== Issue 5767: Adding some filtering capabilities to the Lightweight Logging Service (lwlog-ftf) Click here for this issue's archive. Source: THALES (Ms. Virginie Watine, virginie.watine@fr.thalesgroup.com) Nature: Uncategorized Issue Severity: Summary: In order to add some possibilities to filter records, we would like methods that retrieve log records according to the fields defined in struct ProducerLogRecord (namely the level, producerId and producerName). That would consist in the three following methods to be added on the LogConsumer object. That point has been discussed during the Yokohama meeting with the supporters of this submission (in particular with Jeff Smith) and no difficulty to add these methods was foreseen. Resolution: Revised Text: Actions taken: November 26, 2002: received issue Discussion: Proposed Resolution - To minimize the demands on the log implementation, the original intent of the log specification was to place any responsibility for log filtering or parsing on the client and not on the Log server. As such it is recommended that no changes be made as a result of this request. Subject: RE: LW Log Issue Resolution Vote Date: Tue, 22 Apr 2003 12:15:13 -0400 Thread-Topic: LW Log Issue Resolution Vote Thread-Index: AcMID9RPLMorw3P1EdeMjACgyTbmFwA1pHfA From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h3MGFgsd018690 > > Enclosed is a list of the LW Log issues with proposed resolutions in > bold. Please respond with your vote on the resolutions by Tues. 29 > April. I've received a few new items that I may post on the > issues list > this week and there was also a question regarding the writeRecords > operation that inadvertently was left off the list. > Hi, here's my suggestions: Issue 5767 ---------- I concur with Virginie that a client should not need to download the full log if it is interested in some detail only, e.g. if it wants to find out whether a FAILURE_ALARM occured somewhere. The Log server already has do "parsing" as part as get_record_id_ from_time; I propose to add functionality comparative to this ope- ration, i.e. RecordId get_record_id_with_level (in RecordId currentId, in LogLevel level); RecordId get_record_id_with_producer_id (in RecordId currentId, in string producerId); RecordId get_record_id_with_producer_name (in RecordId currentId, in string producerName); The currentId parameter would give the RecordId where the server starts looking (inclusive). The operations would return the Record Id of the first record with a log that satisfies the condition. The client can then use retrieve_by_id to retrieve the record. This way, the implementation of retrieve_by_id can continue to be as efficient as before. Subject: RE: LW Log Issue Resolution Vote Date: Tue, 22 Apr 2003 12:15:13 -0400 Thread-Topic: LW Log Issue Resolution Vote Thread-Index: AcMID9RPLMorw3P1EdeMjACgyTbmFwA1pHfA From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h3MGFgsd018690 > > Enclosed is a list of the LW Log issues with proposed resolutions in > bold. Please respond with your vote on the resolutions by Tues. 29 > April. I've received a few new items that I may post on the > issues list > this week and there was also a question regarding the writeRecords > operation that inadvertently was left off the list. > Hi, here's my suggestions: Issue 5767 ---------- I concur with Virginie that a client should not need to download the full log if it is interested in some detail only, e.g. if it wants to find out whether a FAILURE_ALARM occured somewhere. The Log server already has do "parsing" as part as get_record_id_ from_time; I propose to add functionality comparative to this ope- ration, i.e. RecordId get_record_id_with_level (in RecordId currentId, in LogLevel level); RecordId get_record_id_with_producer_id (in RecordId currentId, in string producerId); RecordId get_record_id_with_producer_name (in RecordId currentId, in string producerName); The currentId parameter would give the RecordId where the server starts looking (inclusive). The operations would return the Record Id of the first record with a log that satisfies the condition. The client can then use retrieve_by_id to retrieve the record. This way, the implementation of retrieve_by_id can continue to be as efficient as before. Issue 5884 ---------- Agreed. While you're at it, don't forget to adjust the name of LogProducerRecordSequence. Issue 5885 ---------- I support Jeff O's suggestion. Although I'm worried about the "magicness" of a zero return value. So I'd like to amend his suggestion by throwing an InvalidParam exception in the S3 case. Note that the S3 case can never occur due to S1, so it indicates an error on behalf of the client. Issue 5888 - Agreed Issue 5889 - Agreed (in the tables, you can just remove the "void" rows) Issue 5890 - Agreed Subject: LW Log Issue Resolution Vote To: Cc: "Kevin Richardson" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Mon, 28 Apr 2003 10:34:44 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.11 |July 24, 2002) at 04/28/2003 10:34:53 AM X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h3SFaKuO032006 Issues 5767 ? Add Filters - Yes, the proposed changes seem to be out of scope. If filter operations are added then I recommend a different solution by adding a new filter interface that extends the LogConsumer interface, but make this an optional interface for compliancy, not mandatory. 5884 ? IDL Errors -Yes 5885 ? RetrieveByID op - Yes 5888 - Pragma - Yes 5889 ? void- Yes 5890 ? Sponsoring TF - Yes Jerry Bickle Senior Principal Software Engineer Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax From: virginie.WATINE@fr.thalesgroup.com To: lwlog-ftf@omg.org Subject: RE: LW Log Issue Resolution Vote Date: Mon, 28 Apr 2003 18:38:27 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) Hi All, Here is my vote concerning the issues Issue 5767 : No (**) Issue 5884 : Yes Issue 5885 : Yes Issue 5888 : Yes Issue 5889 : Yes Issue 5890 : Yes (**) After having been told, that <> (during the Yokohama meeting), I am a little bit confused to see it now rejected, because it would cause too heavy changes in existing implementations (?!). I cannot imagine that these words were said only to prevent a comment during the official comments phase of the RFC... Am I wrong? Putting a filter on the client side does not achieve at all the same functionality. In particular THALES finds very important to place a filter concerning the "level" on the server side. The other characterictics were added in the issue in order to be regular and cover all the known fields. However, if this could help, we can restrict our initial request to the "level" only. Kind regads, V. -- Virginie Watine T H A L E S COM / SC2 1-5, ave. Carnot / BC4 - 91883 MASSY Cedex Tel : +33 1 69 75 35 56 Fax : +33 1 69 75 31 79 mailto: virginie.watine@fr.thalesgroup.com ------------------------------------------ From: virginie.WATINE@fr.thalesgroup.com To: kwrich@mitre.org Cc: lwlog-ftf@omg.org, virginie.WATINE@fr.thalesgroup.com Subject: RE: LW Log Issue Resolution Vote Date: Wed, 30 Apr 2003 18:55:35 +0200 Importance: high X-Mailer: Internet Mail Service (5.5.2653.19) X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h3UGsveK022445 Hello, I can try to answer to those questions: 1) Why not follow the 'iterator' pattern? ----------------------------------------- Our purpose was to be as less intrusive in the current specification as possible and we felt (may be wrongly) that applying this pattern could be quite complicated at the interface as well as the implementation level. Let's see how this pattern could be introduced, similarly to what exist to access to all the records: - first the application should call an operation (called op1 in the following) to built the list of ids that correspond e.g. to certain levels, - then the application should call (one or several times) an operation to retieve 'howMany' records from that list starting at the 'recordId' passed as an inout parameter (called op2 if the following). This poses several problems : a) how is designated the result of op1 in the call to op2? (we want op2 give reccords resulting from criterium set at op1) b) assuming that the calling client does not call all the needed op2 operations, when is this intermediate result released (I agree that this is an implementation issue)? c) what should be done if some compliant records are recorded between op1 and op2? Another solution would be not to have that op1 and to pass the criterium at each call to op2. In that case, that means that the list is rebuilt at each call to op2 and we need to be very careful regarding the semantics (what if the criterium changes from one call to op2 to the following ?) I don't say that this is insurmountable, so if you think that it would be better to get something that follows that iterator pattern, we are certainly not against: as I said our proposal was just made to be the simplest to implement and the less intrusive in the current baseline... Our unique (but important) requirement is to be able to filter by level on the server side. 2) the word 'records' in the operation name? -------------------------------------------- The purpose of these operations was to retrieve records, by e.g. level, so 'retrieveRecordsByLevel' seemed to us a rather appropriate name. However, if you think that 'retrieveByLevel' is a much better one... well, why not! (to be honnest, I would have prefered 'retrieveRecordsById', rather than 'retrieveById', but life is a matter of compromise ;-) Hope this clarifies. Important: THALES is closed the 1 and 2 of May, as well as the 8 and 9 and I am taking 3 days of vacation in the middle (5,6,7) to fill the gap. Therefore I will be off my office until the 12. When I am off, I cannot reach my THALES mailbox, so please use my home mail address (v.watine@wanadoo.fr - also in CC) during that period. Many thanks in advance and kind regards, V. -- Virginie Watine T H A L E S COM / SC2 1-5, ave. Carnot / BC4 - 91883 MASSY Cedex Tel : +33 1 69 75 35 56 Fax : +33 1 69 75 31 79 mailto: virginie.watine@fr.thalesgroup.com ------------------------------------------ > -----Message d'origine----- > De: Kevin Richardson [mailto:kwrich@mitre.org] > Date: mardi 29 avril 2003 17:34 > @: dwfitkin@rockwellcollins.com; virginie.WATINE@fr.thalesgroup.com > Objet: Re: LW Log Issue Resolution Vote > > > The SCA history of this interface was to not introduce any additional > processing on the server. If bus utilization was an issue we felt that > the system could choose not to honor the request as retrieving log > records would be a very low priority item. The client could police > themselves with the howMany parameter as well. The thought > was that the > client would have more resources available for processing these > requests. > > I don't have a preference as to which approach is promoted - I'm going > to wait to see where the majority goes. However a question that I have > regarding Virginie's initial notes is why it was decided that the new > operations don't have the iterator (howMany/record pointer) > capability. > A poorly formed request could have a worse impact on > processing/bus if a > filtering criteria was chosen that matched most of the records in the > Log. Also why was the word records left in the operation names? > > I don't think that vetoing or not vetoing is a big driver > here. We have > an approach that allows the interested party to vote. It's most likely > that a reasonab Subject: RE: Log... continued Date: Mon, 19 May 2003 10:56:55 -0400 Thread-Topic: Log... continued Thread-Index: AcMeEYGRKaK43on6EdeMjACgyTbmFwABDTMg From: "Pilhofer, Frank" To: "K Richardson" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h4JF0beK018888 > > Here's the latest set of suggestions for discussions - > hopefully we'll be able to wrap this up soon. > Fine with me. Just one observation: If the new operations are mandatory (which I agree with), then the only reason to put them into a new inter- face (which I'm ambivalent about) would be backwards compatibility. However, if you break backwards compatibility by renaming the retrieve_by_id operation (again, ambivalence here), then there's no point in being backwards compatible on the interface level. So if everybody else is fine with 1), 3) and 4), then 2) is not really necessary. 2) makes sense if we don't go ahead with 3) and want to be religious about backwards compatibility. (Although I don't have a problem adding operations to an interface to start with.) Frank X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 19 May 2003 11:15:51 -0400 To: "Pilhofer, Frank" From: Victor Giddings Subject: RE: Log... continued Cc: At 10:56 AM 5/19/2003 -0400, Pilhofer, Frank wrote: > > Here's the latest set of suggestions for discussions - > hopefully we'll be able to wrap this up soon. > Fine with me. Just one observation: If the new operations are mandatory (which I agree with), then the only reason to put them into a new inter- face (which I'm ambivalent about) would be backwards compatibility. Not quite. You will most likely get a smaller footprint if you don't use the new interface. However, if you break backwards compatibility by renaming the retrieve_by_id operation (again, ambivalence here), then there's no point in being backwards compatible on the interface level. So if everybody else is fine with 1), 3) and 4), then 2) is not really necessary. 2) makes sense if we don't go ahead with 3) and want to be religious about backwards compatibility. (Although I don't have a problem adding operations to an interface to start with.) Frank Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 From: To: kwrich@mitre.org Cc: lwlog-ftf@omg.org Subject: Re: Log... continued X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Date: Mon, 19 May 2003 15:14:53 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 5.0.10 |March 22, 2002) at 05/19/2003 03:14:54 PM, Serialize complete at 05/19/2003 03:14:54 PM Kevin, Looks okay to Rockwell Collins. Our only comment is for #2, why bother with the derived interface approach if there is no advantage for doing it that way. We don't see any..... David Fitkin Rockwell Collins "K Richardson" 05/19/2003 09:16 AM To: cc: Subject: Re: Log... continued Hello, Here's the latest set of suggestions for discussions - hopefully we'll be able to wrap this up soon. 1) We'll include interfaces for filtered retrieval by level, producer id and producer name. 2) We'll introduce a new interface for the filtering operations that is derived from the existing log consumer interface. 3) Well modify the operation names as suggested by Virginie: The behavior will be the same as proposed in the third revision of 5767. retrieve_by_id => retrieve_records retrieve_by_level => retrieve_records_by_level retrieve_by_produced_id => retrieve_records_by_producer_id retrieve_by_produced_name => retrieve_records_by_producer_name 4) Implementation of the filtering interface will be manadatory within the spec. (THIS IS STILL THE BIG QUESTION - ARE THERE ANY FTF MEMBERS OTHER THAN JERRY WHO WANT FILTERING TO BE OPTIONAL?). Kevin Date: Tue, 20 May 2003 08:46:50 -0400 From: Kevin Richardson Organization: The MITRE Corporation X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en To: lwlog-ftf@omg.org Subject: Re: Log... continued In looking back at #2 it may be best to take the guidance from David and Frank and not derive this interface. Victor says that we may be able to get a bit of a performance enhancement if we derive and the client chooses not to use the filtering operations. However, I'm a bit stumped about what to do with the discussion of the Log class in section 2 if a new interface is introduced, so I plan on writing up the change today or tomorrow morning with filtering in the Log Consumer interface. Kevin dwfitkin@rockwellcollins.com wrote: > > Kevin, > Looks okay to Rockwell Collins. Our only comment is for #2, why > bother with > the derived interface approach if there is no advantage for doing it > that way. > We don't see any..... > David Fitkin > Rockwell Collins > > "K Richardson" > To: > > 05/19/2003 09:16 AM cc: > Subject: Re: Log... > continued > > Hello, > > Here's the latest set of suggestions for discussions - hopefully we'll > be > able to wrap this up soon. > > 1) We'll include interfaces for filtered retrieval by level, producer > id and > producer name. > 2) We'll introduce a new interface for the filtering operations that > is > derived from the existing log consumer interface. > 3) Well modify the operation names as suggested by Virginie: The > behavior > will be the same as proposed in the third revision of 5767. > retrieve_by_id => retrieve_records > retrieve_by_level => retrieve_records_by_level > retrieve_by_produced_id => retrieve_records_by_producer_id > retrieve_by_produced_name => retrieve_records_by_producer_name > 4) Implementation of the filtering interface will be manadatory within > the > spec. (THIS IS STILL THE BIG QUESTION - ARE THERE ANY FTF MEMBERS > OTHER THAN > JERRY WHO WANT FILTERING TO BE OPTIONAL?). > > Kevin Date: Wed, 21 May 2003 09:37:53 -0400 From: Kevin Richardson Organization: The MITRE Corporation X-Mailer: Mozilla 4.79 [en]C-20020130M (Windows NT 5.0; U) X-Accept-Language: en To: lwlog-ftf@omg.org Subject: Re: Log... continued Enclosed is a copy of the text that reflects our discussions from the last week or so - although as noted below I did not include #2. I also need to figure out how to modify figure 2-1 if we choose to go with this proposal. Worst case, I can regenerate the model by hand. Kevin Kevin Richardson wrote: > > In looking back at #2 it may be best to take the guidance from David and > Frank and not derive this interface. Victor says that we may be able to > get a bit of a performance enhancement if we derive and the client > chooses not to use the filtering operations. However, I'm a bit stumped > about what to do with the discussion of the Log class in section 2 if a > new interface is introduced, so I plan on writing up the change today or > tomorrow morning with filtering in the Log Consumer interface. > Kevin > > dwfitkin@rockwellcollins.com wrote: > > > > Kevin, > > Looks okay to Rockwell Collins. Our only comment is for #2, why > > bother with > > the derived interface approach if there is no advantage for doing it > > that way. > > We don't see any..... > > David Fitkin > > Rockwell Collins > > > > "K Richardson" > > To: > > > > 05/19/2003 09:16 AM cc: > > Subject: Re: Log... > > continued > > > > Hello, > > > > Here's the latest set of suggestions for discussions - hopefully we'll > > be > > able to wrap this up soon. > > > > 1) We'll include interfaces for filtered retrieval by level, producer > > id and > > producer name. > > 2) We'll introduce a new interface for the filtering operations that > > is > > derived from the existing log consumer interface. > > 3) Well modify the operation names as suggested by Virginie: The > > behavior > > will be the same as proposed in the third revision of 5767. > > retrieve_by_id => retrieve_records > > retrieve_by_level => retrieve_records_by_level > > retrieve_by_produced_id => retrieve_records_by_producer_id > > retrieve_by_produced_name => retrieve_records_by_producer_name > > 4) Implementation of the filtering interface will be manadatory within > > the > > spec. (THIS IS STILL THE BIG QUESTION - ARE THERE ANY FTF MEMBERS > > OTHER THAN > > JERRY WHO WANT FILTERING TO BE OPTIONAL?). > > > > Kevin Log Resolution Text.pdf Subject: RE: Log... continued Date: Wed, 21 May 2003 16:43:47 -0400 Thread-Topic: Log... continued Thread-Index: AcMfnmlGAwmlQot+EdeMjACgyTbmFwAOwMoQ From: "Pilhofer, Frank" To: "Kevin Richardson" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h4LKlleK029796 > > Enclosed is a copy of the text that reflects our discussions from the > last week or so - although as noted below I did not include #2. > Fine with me. Note that StringSequence should be replaced with CORBA::StringSeq. Frank X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 21 May 2003 18:17:13 -0400 To: Kevin Richardson From: Victor Giddings Subject: Re: Log... continued Cc: lwlog-ftf@omg.org At 09:37 AM 5/21/2003 -0400, Kevin Richardson wrote: Enclosed is a copy of the text that reflects our discussions from the last week or so - although as noted below I did not include #2. I also need to figure out how to modify figure 2-1 if we choose to go with this proposal. Worst case, I can regenerate the model by hand. Kevin I've annotated the text in the attached pdf. You should be able to see the annotations in full Acrobat or with Acrobat Reader 5. To summarize: - section 3.3.2.1 change: cut and paste error - replace getRecordIdFromTime with get_record_id_from_time - new sections 2.4.3 and following: strike "If there are no further records available, currentId will be set to zero." (3 occurrences) This should not be done by these operations; it leads to an unrecoverable condition if you iterate past the end of the current log contents. CurrentId should be set to the next record ID that will be recorded. - IDL problems: -- corrected the final parameter for the new operations -- defined LogLevelSequence. (I also changed constant types for the LogLevel "enumerations" since that was obviously intended.) -- change StringSequence to CORBA::StringSeq Another IDL issue: why are we defining a new time type and not using TimeBase::TimeT? I've also attached the updated IDL file that reflects these corrections for review. In addition to the substantive changes, I've introduced the "CORBA 3" IDL modifications (typeprefix, etc.). The result compiles successfully with our IDL compilers. Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 Log Resolution Text-annotated.pdf proposed-vote3.idl X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 21 May 2003 18:25:27 -0400 To: Kevin Richardson From: Victor Giddings Subject: Re: Log... continued Cc: lwlog-ftf@omg.org At 04:53 PM 5/21/2003 -0400, Kevin Richardson wrote: Here's a copy of the figure. I wasn't able to get Rose to display the operations in the Log class. Kevin Since Log is a conceptual implementation artifact (not a subject of the specification), why attempt to? In fact, why not hide the attributes too? Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501 X-Sender: giddiv@postel X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 23 May 2003 16:34:05 -0400 To: Kevin Richardson From: Victor Giddings Subject: Re: Log... continued Cc: lwlog-ftf@omg.org At 03:35 PM 5/23/2003 -0400, Kevin Richardson wrote: I thought a bit more today, and I'm going to leave the zero remark in that we discussed earlier because of one odd case that I recalled. If you save a current Id pointer too long and have the log full action set to wrap then you may get a false sense of security with respect to the records that you are examining. Kevin I'm not getting this. Record Ids shouldn't wrap: "The writeRecords operation inserts the current UTC time to the time field of each record written to the Log, and assigns a unique record Id to the id field of the LogRecord." The scenario I am thinking of: Log capacity 20 Log contents 10 - 5 of which pass the filter criteria. Issue a retrieve_records_by_xxx(currentId => 1, howMany => 15, valueList => yyy); So on return howMany = 5 and currentId = 0 (!). Another 5 items are subsequently logged. How do I issue another retrieve_records_by_xxx to see if these meet the criteria? Victor Giddings wrote: > > At 04:53 PM 5/21/2003 -0400, Kevin Richardson wrote: > > >Here's a copy of the figure. I wasn't able to get Rose to display the > >operations in the Log class. > >Kevin > > Since Log is a conceptual implementation artifact (not a subject of the > specification), why attempt to? In fact, why not hide the attributes too? > > Victor Giddings mailto:victor.giddings@ois.com > Senior Product Engineer +1 703 295 6500 > Objective Interface Systems Fax: +1 703 295 6501 Victor Giddings mailto:victor.giddings@ois.com Senior Product Engineer +1 703 295 6500 Objective Interface Systems Fax: +1 703 295 6501