Issue 5884: LW Log Service IDL errors (lwlog-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: The Lightweight Log draft adopted specification contains some errors in its IDL. There is a struct called ProducerLogRecord, which is being referred to later on as LogProducerRecord in the LogProducer interface (page 56). Furthermore, the LogFullAction enum is wrongly referred to as LogFullActionType. The same goes for AdministrativeState which is being referred to as AdministrativeStateType from the LogAdministrator interface definition. Resolution: Revised Text: Actions taken: March 13, 2003: received issue Discussion: End of Annotations:===== X-Sender: linda@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 09:28:27 -0500 To: juergen Boldt From: Linda Heaton Subject: Fwd: OMG Document ptc/02-11-02 Issue?? From: "Panagiotis Issaris" Date: Thu, 13 Mar 2003 15:19:53 +0100 To: linda@omg.org Subject: OMG Document ptc/02-11-02 Reply-To: takis@lumumba.luc.ac.be User-Agent: Mutt/1.5.3i Dear Ms. Heaton, The Lightweight Log draft adopted specification contains some errors in its IDL. There is a struct called ProducerLogRecord, which is being referred to later on as LogProducerRecord in the LogProducer interface (page 56). Furthermore, the LogFullAction enum is wrongly referred to as LogFullActionType. The same goes for AdministrativeState which is being referred to as AdministrativeStateType from the LogAdministrator interface definition. With friendly regards, Panagiotis Issaris -- e-mail: takis@lumumba.luc.ac.be OpenPGP key: http://lumumba.luc.ac.be/takis/takis_public_key.txt fingerprint: 6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 E029 IM: takis@jabber.org, icq(12764288), t4k1s@yahoo.com Issue 5884: LW Log Service IDL errors (lwlog-ftf) Click here for this issue's archive. Nature: Uncategorized Issue Severity: Summary: The Lightweight Log draft adopted specification contains some errors in its IDL. There is a struct called ProducerLogRecord, which is being referred to later on as LogProducerRecord in the LogProducer interface (page 56). Furthermore, the LogFullAction enum is wrongly referred to as LogFullActionType. The same goes for AdministrativeState which is being referred to as AdministrativeStateType from the LogAdministrator interface definition. Resolution: Revised Text: Actions taken: March 13, 2003: received issue Proposed Resolution - convert the occurrences of LogProducerRecord to ProducerLogRecord In the IDL replace LogFullActionType with LogFullAction. In the IDL and the AdministrativeState PSM section replace AdminstrativeStateType with AdministrativeState. Issue 5884 ---------- Agreed. While you're at it, don't forget to adjust the name of LogProducerRecordSequence. 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