Issue 547: list_types needs iterator (zz-trader) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: The list_types operation in the trader service type repository returns a sequence of service type names. This will break badly if the number of types is large. Modify Resolution: Revised Text: Actions taken: April 21, 1997: received issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Mon, 21 Apr 1997 14:04:39 +1000 (EST) From: Michi Henning cc: trader-tech@dstc.edu.au Subject: list_types needs iterator Errors-To: owner-issues Sender: owner-issues X-OMG: issues To: issues Hi, the list_types operation in the trader service type repository returns a sequence of service type names. This will break badly if the number of types is large. list_types should be modified to return an iterator object if many service types need to be returned. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Cc: issues@omg.org, trader-tech@dstc.edu.au Subject: Re: [trader-tech] list_types needs iterator Date: Tue, 29 Apr 1997 18:07:51 +1000 From: Kerry Raymond Errors-To: owner-issues Sender: owner-issues X-OMG: issues To: issues > the list_types operation in the trader service type repository returns > a sequence of service type names. This will break badly if the number of > types is large. > list_types should be modified to return an iterator object if many > service types need to be returned. I have two points: 1. I wish the AB (or someone) would issue some definition statement on the "when, where, and how" of iterators in CORBA specs. Some services use them, others don't, and there are many different flavours of them. 2. In terms of revising the trader, this is hopefully a non-issue. Read on for the history lesson ... The service type repository in the trader spec is only intended as a stop-gap measure. There was considerable discussion about the right place "architecturally" to store service type definitions, and that discussion was ultimately raised to the AB for their authorative opinion. The consensus seemed to be that existing repositories (in particular the Interface Repository) was not the right place, but that the Meta-Object Facility was the logical place for such information. However, at that time, the Meta-Object Facility only existed as a RFP being drafted, so the Trader submitters were left with a choice of: a) not having any service type repository and effectively preventing any realistic way to federate traders (since proprietary service type repositories would get built) b) define a temporary service type repository to be replaced by using the Meta-Object Facility once that RFP had completed. The submitters chose the latter course of action and (in some haste) prepared the service type repository interface as a seperate part of the trader specification (to ease its anticipated replacement). Kerry >>>> 1st International Enterprise Distributed Object Computing Workshop <<<< >>>>>> Oct 24-26 1997 http://www.dstc.edu.au/events/edoc97/edoc.html <<<<<< ============================================================================= Dr Kerry Raymond, Architecture Unit Leader E-mail: kerry@dstc.edu.au CRC for Distributed Systems Technology Phone: +61 7 3365 4310 University of Queensland 4072 Australia Fax: +61 7 3365 4311 =========================================== WWW: http://www.dstc.edu.au/kerry Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Tue, 29 Apr 1997 18:20:40 +1000 (EST) From: Michi Henning cc: issues@omg.org, trader-tech@dstc.edu.au Subject: Re: [trader-tech] list_types needs iterator Errors-To: owner-issues Sender: owner-issues X-OMG: issues To: issues > I have two points: > > 1. I wish the AB (or someone) would issue some definition statement on > the "when, where, and how" of iterators in CORBA specs. Some services > use them, others don't, and there are many different flavours of them. Yes, I agree, that would be nice. It also reminds me that our pretty life cycle spec has been largely ignored. For example, the iterators for the trader and many other services still use destroy(), instead of inheriting from LifeCycleObject. I know, there is historical precedent for it, but it begs the question of why we have a life cycle spec at all when even the OMG refuses to use it for its own services... > 2. In terms of revising the trader, this is hopefully a non-issue. Read on > for the history lesson ... Kerry, I know about the background for the service type repository, and I realize it was added as a stop-gap. However, until the real thing comes along, we'll have to live with the stop-gap. Now the stop-gap has a flaw that causes problems as the number of types gets large. I'm the first to admit that the absence of an iterator isn't a major issue, and it wasn't meant to be a slur on the people who spent sleepless nights to get the spec finished on time. I simply pointed out a potential problem in the spec. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Date: Wed, 21 Mar 2001 10:57:02 +1000 (EST) From: Michi Henning To: Juergen Boldt cc: issues@emerald.omg.org Subject: Re: Lost issues In-Reply-To: <4.2.0.58.20010320104951.00a86ca0@emerald.omg.org> Message-ID: Organization: Object Oriented Concepts - An IONA Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: :BJe9a1K!!,[8e9=SL!! On Tue, 20 Mar 2001, Juergen Boldt wrote: > Hello all, > > URL http://cgi.omg.org/issues/issues.html > contains links to issues which have not been assigned to R/FTFs > because of > a couple of reasons: > ..to name a few... > a) The RTF/FTF has expired and should be re-chartered > b) The RTF/FTF has expired and will never be re-chartered again > (several > reasons why are possible) > c) I just didn't know what RTF/FTF would be responsible for an issue > submitted.. > d) There appear to be no RTFs for most of the CORBAservices > e) Nobody knew about this issues archive > > With your help some of those issues could be resolved (by assigning > some of > those issues to active RTFs/FTFs or by rechartering some of the > expired > RTFs...) Here are some proposals: Issue 184: Close no change. I don't understand the question Issue 468: Close. The issue is empty. Issue 493: Close no change. It doesn't because the submitters decided that it wouldn't. Issue 498: From what I can recall, this refers to name equivalence in the Naming Service. INS has cleaned this, so close it. Issue 961: Move to http://cgi.omg.org/issues/event-rtf.html Issue 2347: Close. This was fixed by INS. Issue 2972: Move to http::/cgi.omg.org/issues/relationship-rtf.html Issue 3003: Close. Issue 3271: Close no change. Historically, iterators in the various specs are a total mess, and all of them, without exception, get it wrong :-( I'm afraid we have to live with the resulting inconsistencies. Issue 4216: Should probably be reassigned to Core RTF? Issues 284, 546, 547, 548, 549, 550, 558, 559, 560, 561, 562, 4225: We need a trader RTF for those. The remaining open issues also will require formation of RTFs. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts - An IONA Company +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi.henning@iona.com Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi