Issue 3082: local interface PollableSet: why? (messaging-rtf) Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com) Nature: Uncategorized Issue Severity: Summary: Given the possible misconception of the relationship between valuetypes and interfaces at the time the messaging spec was submitted, I would like to question the definition of PollableSet as a local interface (locality-constrained objects). The purpose of PollableSet is to provide a container of pollers. Fundamentally, the container could (a) potentially be remote, or (b) always be local In case (a) it could be defined by a non-local interface, in case (b) by a valuetype. However, it is currently defined as a local interface. For what reason? Is it for that PollableSet references cannot be passed around (i), or for that PollableSet invocations are local to the process (ii)? Note that if (i) is not a requirement, then PollableSet could be defined as a valuetype for the same reason that poller was defined as a valuetype. [Extract from a disussion about pollers as value, http://www.omg.org/archives/messaging/msg00041.html : The Poller consists of two components: (a) typed stubs through which operation results can be obtained by a client application (b) persistent state allowing the implementation of these operations to query the Messaging internals to obtain the reply to a previous request. This looks to me like exactly what you would encapsulate in a Value. Prior to OVB, you would have to specify such an object in PIDL as a pseudo-object (such as the current CORBA::Request for DII). OBV gives us the ability to no longer require such pseudo-IDL when specifying these "objects with state". ] Why not define PollableSet as a valuetype? This would have the advantage that a PollableSet can be passed as an argument to an operation. What's so much different between a PollableSet and an array of pollers, such that PollableSet must be locality-constrained? Resolution: Close this issue Revised Text: Actions taken: December 6, 1999: received issue January 9, 2001: closed issue Discussion: Basically, I see 2 possible resolutions: (a) leave PollableSet locality-constrained (b) change (local) interface PollableSet to a valuetype The idea of (b) would be that a pollable set could be passed to another polling client just as pollers. However, for interoperability reasons, this would require that the PollableSet valuetype also defines the state members. This wouldn't be difficult, however, there is no need for this, as the application can already do this by defining a sequence of pollers. But most important, it is unlikely that an application wants to pass around pollable sets at all because pollable sets are usually only created by the polling client that is going to receive the replies. Therefore I think it makes most sense to leave PollableSet locality-constrained as defined by the original submitters. Proposed Resolution: Close this issue End of Annotations:===== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Mon, 6 Dec 1999 10:30:57 +0100 Message-Id: Subject: local interface PollableSet: why? MIME-Version: 1.0 TO: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 6 Dec 1999 10:30:57 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Mon, 6 Dec 1999 10:30:57 +0100" X-UIDL: 6KWd9Wi~!!]CF!!*9hd9 Given the possible misconception of the relationship between valuetypes and interfaces at the time the messaging spec was submitted, I would like to question the definition of PollableSet as a local interface (locality-constrained objects). The purpose of PollableSet is to provide a container of pollers. Fundamentally, the container could (a) potentially be remote, or (b) always be local In case (a) it could be defined by a non-local interface, in case (b) by a valuetype. However, it is currently defined as a local interface. For what reason? Is it for that PollableSet references cannot be passed around (i), or for that PollableSet invocations are local to the process (ii)? Note that if (i) is not a requirement, then PollableSet could be defined as a valuetype for the same reason that poller was defined as a valuetype. [Extract from a disussion about pollers as value, http://www.omg.org/archives/messaging/msg00041.html : The Poller consists of two components: (a) typed stubs through which operation results can be obtained by a client application (b) persistent state allowing the implementation of these operations to query the Messaging internals to obtain the reply to a previous request. This looks to me like exactly what you would encapsulate in a Value. Prior to OVB, you would have to specify such an object in PIDL as a pseudo-object (such as the current CORBA::Request for DII). OBV gives us the ability to no longer require such pseudo-IDL when specifying these "objects with state". ] Why not define PollableSet as a valuetype? This would have the advantage that a PollableSet can be passed as an argument to an operation. What's so much different between a PollableSet and an array of pollers, such that PollableSet must be locality-constrained? Any comment? Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 X-Sender: siegel@192.67.184.65 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 06 Dec 1999 08:38:44 -0500 To: hans.kneubuehl@ubs.com, messaging-rtf@omg.org From: Jon Siegel Subject: Re: local interface PollableSet: why? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: $IU!!-GV!!b'>e9?3~e9 Hi All -- I talked to Jon Goldberg and Dan Frantz as I wrote up Messaging for my forthcoming book, and this was one of the topics we covered. Here's how they explained it to me: The poller is supposed to be locally restricted unless the site has implemented routers with persistent storage and ROUTE_STORE_AND_FORWARD is in effect. There is an advantage to this: it allows clients to link with client libraries only (assuming they're not using *any* callbacks, either for messaging or for events/notification), producing a much lighter-weight executable than would result if they used callbacks which require the server-side library also be included in the link step. However, if the site has persistent routers and ROUTE_STORE_AND_FORWARD is in effect, the router can store the result and pollers can poll the router. I believe that this does require server-side libraries but don't recall exactly why. In any case, this scenario was considered useful enough that it was made the behavior when persistent routers were available and the proper routing policy was set. When I teach messaging as part of the CORBA tutorial and explain the way polling slims down a client executable, audiences are generally appreciative so don't sell this advantage short! Does this help? Jon Siegel At 10:30 AM 12/6/1999 +0100, hans.kneubuehl@ubs.com wrote: >Given the possible misconception of the relationship between valuetypes and >interfaces at the time the messaging spec was submitted, I would like to >question the definition of PollableSet as a local interface >(locality-constrained objects). > >The purpose of PollableSet is to provide a container of pollers. > >Fundamentally, the container could >(a) potentially be remote, or >(b) always be local > >In case (a) it could be defined by a non-local interface, in case (b) by a >valuetype. However, it is currently defined as a local interface. For what >reason? Is it for that PollableSet references cannot be passed around (i), or >for that PollableSet invocations are local to the process (ii)? Note that if >(i) is not a requirement, then PollableSet could be defined as a valuetype for >the same reason that poller was defined as a valuetype. > >[Extract from a disussion about pollers as value, >http://www.omg.org/archives/messaging/msg00041.html : >The Poller consists of two components: > >(a) typed stubs through which operation results can be >obtained by a client application >(b) persistent state allowing the implementation of these >operations to query the Messaging internals to obtain >the reply to a previous request. > >This looks to me like exactly what you would encapsulate >in a Value. Prior to OVB, you would have to specify >such an object in PIDL as a pseudo-object (such as the >current CORBA::Request for DII). OBV gives us >the ability to no longer require such pseudo-IDL when >specifying these "objects with state". >] > >Why not define PollableSet as a valuetype? This would have the advantage that a >PollableSet can be passed as an argument to an operation. > >What's so much different between a PollableSet and an array of pollers, such >that PollableSet must be locality-constrained? > > >Any comment? > > >Regards >Hans >-- >Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland >phone: +41 1 238 28 96, fax: +41 1 238 30 11 ================================================================== Jon Siegel Phone: 508-820-4300 X124 Director, Technology Transfer Fax: 508-820-4303 Object Management Group 492 Old Connecticut Path email: siegel@omg.org Framingham, Massachusetts 01701 USA http://www.omg.org ================================================================== Date: Tue, 07 Dec 1999 02:18:35 +0100 From: Hans Kneub|hl Reply-To: hans@smtp.datacomm.ch X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sigel@omg.org, messaging-rtf@omg.org Subject: Re: local interface PollableSet: why? -> why not Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f7Zd9^Pj!!^VM!!D'\d9 Jon, your saying the poller is supposed to be locally restricted unless the site has implemented routers with persistent storage in which case the routers store the reply. Is it then correct to conclude from this that pollable sets are supposed to be locally restricted UNLESS the site has implemented routers with persistent storage? This would mean that pollable set should be defined as a valuetype just like pollers. Regards Hans siegel@omg.org wrote: > Hi All -- > > I talked to Jon Goldberg and Dan Frantz as I wrote up Messaging > for my forthcoming book, and this was one of the topics we covered. > Here's how they explained it to me: > > The poller is supposed to be locally restricted unless the site > has implemented routers with persistent storage and > ROUTE_STORE_AND_FORWARD is in effect. There is an advantage to > this: it allows clients to link with client libraries only > (assuming they're not using *any* callbacks, either for messaging > or for events/notification), producing a much lighter-weight > executable than would result if they used callbacks which require > the server-side library also be included in the link step. > > However, if the site has persistent routers and > ROUTE_STORE_AND_FORWARD is in effect, the router can store the > result and pollers can poll the router. I believe that this does > require server-side libraries but don't recall exactly why. In > any case, this scenario was considered useful enough that it was > made the behavior when persistent routers were available and the > proper routing policy was set. > > When I teach messaging as part of the CORBA tutorial and explain > the way polling slims down a client executable, audiences are > generally appreciative so don't sell this advantage short! > > Does this help? > > Jon Siegel > > > At 10:30 AM 12/6/1999 +0100, hans.kneubuehl@ubs.com wrote: > > >Given the possible misconception of the relationship between > valuetypes and > >interfaces at the time the messaging spec was submitted, I would > like to > >question the definition of PollableSet as a local interface > >(locality-constrained objects). > > > >The purpose of PollableSet is to provide a container of pollers. > > > >Fundamentally, the container could > >(a) potentially be remote, or > >(b) always be local > > > >In case (a) it could be defined by a non-local interface, in case > (b) by a > >valuetype. However, it is currently defined as a local > interface. For what > >reason? Is it for that PollableSet references cannot be passed > around (i), or > >for that PollableSet invocations are local to the process (ii)? > Note that if > >(i) is not a requirement, then PollableSet could be defined as a > valuetype for > >the same reason that poller was defined as a valuetype. > > > >[Extract from a disussion about pollers as value, > >http://www.omg.org/archives/messaging/msg00041.html : > >The Poller consists of two components: > > > >(a) typed stubs through which operation results can be > >obtained by a client application > >(b) persistent state allowing the implementation of these > >operations to query the Messaging internals to obtain > >the reply to a previous request. > > > >This looks to me like exactly what you would encapsulate > >in a Value. Prior to OVB, you would have to specify > >such an object in PIDL as a pseudo-object (such as the > >current CORBA::Request for DII). OBV gives us > >the ability to no longer require such pseudo-IDL when > >specifying these "objects with state". > >] > > > >Why not define PollableSet as a valuetype? This would have the > advantage that a > >PollableSet can be passed as an argument to an operation. > > > >What's so much different between a PollableSet and an array of > pollers, such > >that PollableSet must be locality-constrained? > > > > > >Any comment? > > > > > >Regards > >Hans > >-- > >Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > >phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > ================================================================== > Jon Siegel Phone: 508-820-4300 X124 > Director, Technology Transfer Fax: 508-820-4303 > Object Management Group > 492 Old Connecticut Path email: siegel@omg.org > Framingham, Massachusetts 01701 USA http://www.omg.org > ================================================================== > > X-Sender: siegel@192.67.184.65 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 06 Dec 1999 22:25:42 -0500 To: hans@smtp.datacomm.ch, siegel@omg.org, messaging-rtf@omg.org From: Jon Siegel Subject: Re: local interface PollableSet: why? -> why not In-Reply-To: <384C606B.D2FB0D3D@datacomm.ch> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 789e9XZ?e9^AI!!:#`d9 Hi again -- Sorry but you guys are on your own from here. I've reported all I remember from a fairly confusing series of conversations (and I wasn't the only confused one :-) We never discussed pollable sets; just the poller return type, as I recall. Even if I studied the spec on pollable sets, I wouldn't turn into an expert, able to give authoritative advice. Good luck! -- Jon S. At 02:18 AM 12/7/1999 +0100, Hans Kneub|hl wrote: >Jon, > >your saying the poller is supposed to be locally restricted unless the >site has implemented routers with persistent storage in which case the >routers store the reply. > >Is it then correct to conclude from this that pollable sets are supposed >to be locally restricted UNLESS the site has implemented routers with >persistent storage? > >This would mean that pollable set should be defined as a valuetype just >like pollers. > >Regards >Hans > >siegel@omg.org wrote: > > Hi All -- > > > > I talked to Jon Goldberg and Dan Frantz as I wrote up Messaging > > for my forthcoming book, and this was one of the topics we covered. > > Here's how they explained it to me: > > > > The poller is supposed to be locally restricted unless the site > > has implemented routers with persistent storage and > > ROUTE_STORE_AND_FORWARD is in effect. There is an advantage to > > this: it allows clients to link with client libraries only > > (assuming they're not using *any* callbacks, either for messaging > > or for events/notification), producing a much lighter-weight > > executable than would result if they used callbacks which require > > the server-side library also be included in the link step. > > > > However, if the site has persistent routers and > > ROUTE_STORE_AND_FORWARD is in effect, the router can store the > > result and pollers can poll the router. I believe that this does > > require server-side libraries but don't recall exactly why. In > > any case, this scenario was considered useful enough that it was > > made the behavior when persistent routers were available and the > > proper routing policy was set. > > > > When I teach messaging as part of the CORBA tutorial and explain > > the way polling slims down a client executable, audiences are > > generally appreciative so don't sell this advantage short! > > > > Does this help? > > > > Jon Siegel > > > > > > At 10:30 AM 12/6/1999 +0100, hans.kneubuehl@ubs.com wrote: > > > > >Given the possible misconception of the relationship between valuetypes and > > >interfaces at the time the messaging spec was submitted, I would like to > > >question the definition of PollableSet as a local interface > > >(locality-constrained objects). > > > > > >The purpose of PollableSet is to provide a container of pollers. > > > > > >Fundamentally, the container could > > >(a) potentially be remote, or > > >(b) always be local > > > > > >In case (a) it could be defined by a non-local interface, in case (b) by a > > >valuetype. However, it is currently defined as a local interface. For what > > >reason? Is it for that PollableSet references cannot be passed around (i), or > > >for that PollableSet invocations are local to the process (ii)? Note that if > > >(i) is not a requirement, then PollableSet could be defined as a valuetype for > > >the same reason that poller was defined as a valuetype. > > > > > >[Extract from a disussion about pollers as value, > > >http://www.omg.org/archives/messaging/msg00041.html : > > >The Poller consists of two components: > > > > > >(a) typed stubs through which operation results can be > > >obtained by a client application > > >(b) persistent state allowing the implementation of these > > >operations to query the Messaging internals to obtain > > >the reply to a previous request. > > > > > >This looks to me like exactly what you would encapsulate > > >in a Value. Prior to OVB, you would have to specify > > >such an object in PIDL as a pseudo-object (such as the > > >current CORBA::Request for DII). OBV gives us > > >the ability to no longer require such pseudo-IDL when > > >specifying these "objects with state". > > >] > > > > > >Why not define PollableSet as a valuetype? This would have the advantage that a > > >PollableSet can be passed as an argument to an operation. > > > > > >What's so much different between a PollableSet and an array of pollers, such > > >that PollableSet must be locality-constrained? > > > > > > > > >Any comment? > > > > > > > > >Regards > > >Hans > > >-- > > >Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > > >phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > > > > ================================================================== > > Jon Siegel Phone: 508-820-4300 X124 > > Director, Technology Transfer Fax: 508-820-4303 > > Object Management Group > > 492 Old Connecticut Path email: siegel@omg.org > > Framingham, Massachusetts 01701 USA http://www.omg.org > > ================================================================== > > > > ================================================================== Jon Siegel Phone: 508-820-4300 X124 Director, Technology Transfer Fax: 508-820-4303 Object Management Group 492 Old Connecticut Path email: siegel@omg.org Framingham, Massachusetts 01701 USA http://www.omg.org ================================================================== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Sat, 11 Mar 2000 04:12:58 +0100 Message-Id: Subject: 3082 (locality-constrained PollableSet): straw man proposal MIME-Version: 1.0 TO: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sat, 11 Mar 2000 04:12:58 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Sat, 11 Mar 2000 04:12:58 +0100" X-UIDL: C-]!!ATZ!!kl;!!AB'!! >Issue 3082: local interface PollableSet: why? (messaging-rtf) > >Summary: Given the possible misconception of the relationship between valuetypes and >interfaces at the time the messaging spec was submitted, I would like to >question the definition of PollableSet as a local interface (locality-constrained >objects). The purpose of PollableSet is to provide a container of pollers. Fundamentally, >the container could (a) potentially be remote, or (b) always be local In case (a) it >could be defined by a non-local interface, in case (b) by a valuetype. However, it is >currently defined as a local interface. For what reason? Is it for that PollableSet >references cannot be passed around (i), or for that PollableSet invocations are local to >the process (ii)? Note that if (i) is not a requirement, then PollableSet could be >defined as a valuetype for the same reason that poller was defined as a valuetype. >[Extract from a disussion about pollers as value, > http://www.omg.org/archives/messaging/msg00041.html : The Poller consists of two >components: (a) typed stubs >through which operation results can be obtained by a client application (b) persistent >state allowing the implementation of these operations to query the Messaging >internals to obtain the reply to a previous request. This looks to me like exactly what >you would encapsulate in a Value. Prior to OVB, you would have to specify such >an object in PIDL as a pseudo-object (such as the current CORBA::Request for DII). OBV >gives us the ability to no longer require such pseudo-IDL when specifying >these "objects with state". ] Why not define PollableSet as a valuetype? This would have >the advantage that a PollableSet can be passed as an argument to an >operation. What's so much different between a PollableSet and an array of pollers, such >that PollableSet must be locality-constrained? Resolution Proposal: -------------------- close without change Rational: --------- Basically, I see 2 possible resolutions: (a) leave PollableSet locality-constrained (b) change (local) interface PollableSet to a valuetype The idea of (b) would be that a pollable set could be passed to another polling client just as pollers. However, for interoperability reasons, this would require that the PollableSet valuetype also defines the state members. This wouldn't be difficult, however, there is no need for this, as the application can already do this by defining a sequence of pollers. But most important, it is unlikely that an application wants to pass around pollable sets at all because pollable sets are usually only created by the polling client that is going to receive the replies. Therefore I think it makes most sense to leave PollableSet locality-constrained as defined by the original submitters. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11