Issue 4250: Proposal to support interposition (Active Service spec orbos/2000-06-19) (ots-structs-ftf) Source: International Business Machines (Dr. Ian Robinson, ian_robinson@uk.ibm.com) Nature: Uncategorized Issue Severity: Summary: The problem is that, in domain 2 where there is no SignalSet, how are the Outcomes from Action1 and Action2 supposed to be combined and sent back as a single Outcome to the superior ActivityCoordinator? Further, even if the appropriate SignalSet did exist in domain 2, how could the subordinate ActivityCoordinator get it involved in the request from the superior - the interposed ActivityCoordinator is merely acting as a global Action registered with its superior. I propose the following in order to support interposition: 1. Any signal received by a subordinate ActivityCoordinator be delegated to a SignalSet (assumed to be local since we're using interposition). If the SignalSet is not available, then return a standard Outcome (that also needs to be specified) that indicates that the subordinate ActivityCoordinator is not interested in any further signals from this particular broadcast. 2. Extend the CosActivity::SignalSet interface to provide a set_signal(signal) method to enable a subordinate ActivityCoordinator to indicate to the SignalSet that it will be used only to process the specified Signal (and the Outcomes that are subsequently produced by Actions that receive the Signal) and not to actually produce any Signals. Only the root SignalSet should be producing Signals. An alternative would be to split the SignalSet into 2 objects - the function of 1 object being to produce Signals and the other to combine Outcomes. The down-side of this is the additional complexity it introduces in terms of additional flows between the 2 parts of the SignalSet in the root. Another alternative would be to specialize the SignalSet with a SubordinateSignalSet. Resolution: Update the specification to incorporate a new entity, the SubordinateSignalSet Revised Text: A domain that contains an interposed, subordinate ActivityCoordinator can support Actions registering at that subordinate ActivityCoordinator with an interest in, say, SignalSet "X". The subordinate ActivityCoordinator must use a specialised implementation of X that supports a SubordinateSignalSet interface. The SubordinateSignalSet interface is added to CosActivity module as follows: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ interface Subordinate SignalSet : SignalSet { void set_signal (in Signal signal); Outcome get_current_outcome() raises SignalSetInactive; }; set_signal Sets the Signal to be sent to the Action objects registered for this SubordinateSignalSet. This method is called by a subordinate ActivityCoordinator when it receives a Signal from its superior. The subordinate ActivityCoordinator distributes this Signal to each appropriate Action and passes each Action Outcome back to the SubodinateSignalSet via the set_response method. The SubordinateSignalSet produces a combined Outcome for the set Signal and this is returned by the subordinate ActivityCoordinator to its superior. Any system exceptions raised by the SubordinateSignalSet should be converted to an ActionError by the subordinate ActivityCoordinator. get_current_outcome Returns an intermediate outcome of the SubordinateSignalSet. This may be called after the processing of each Signal and is used by a subordinate ActivityCoordinator to obtain an Outcome to return to its superior in response to a received Signal. If the SignalSet has not been initialized, for example by a call to set_signal, then the SignalSetInactive exception will be thrown. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The SignalSetInactive Exception description should be changed to the following: The SignalSetInactive exception is raised by the SignalSet if an attempt is made to use the SignalSet without having first called get_signal or set_signal. The third paragraph of "2.2.10 Interposition" refers to the use of global actions as a means to implement interposition and should be changed to say the following: A subordinate ActivityCoordinators registers itself with its parent as an Action, with an interest in the Synchronization SignalSet. An Action may be subsequently registered with the subordinate ActivityCoordinator with an interest in a particular SignalSet that is available to the root ActivityCoordinator. The subordinate ActivityCoordinator must have a SubordinateSignalSet implementation available to it and should register an Action with an interest in a SignalSet of the same name with its superior ActivityCoordinator. When the subordinate ActivityCoordinator receives a Signal from its superior it calls the set_signal method on the SubordinateSignalSet passing the Signal as a parameter. The subordinate must then forward the Signal to any appropriate Action that registered with it (including other subordinate ActivityCoordinators) and pass each Outcome received to the SubordinateSignalSet. The role of the SubordinateSignalSet is to combine the Outcomes produced into a single Outcome that can be returned to the superior by the subordinate ActivityCoordinator. Once a subordinate ActivityCoordinator has completed distributing a received Signal, it should ask the SubordinateSignalSet for the next signal in case the SubordinateSignalSet is able to produce another Signal, independently of any superior SignalSet, which the subordinate ActivityCoordinator should distribute to any appropriate Actions. Any such Signals are produced as a performance optimization by the SubordinateSignalSet and must not change the Outcome that was produced as a result of the Signal received from the superior. Actions taken: April 5, 2001: received issue May 2, 2003: closed issue Discussion: End of Annotations:===== From: ian_robinson@uk.ibm.com Received: from d06mta05.portsmouth.uk.ibm.com (d06mta05_cs0 [9.180.35.3]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id OAA281932; Thu, 5 Apr 2001 14:05:43 +0100 Received: by d06mta05.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A25.0047EE05 ; Thu, 5 Apr 2001 14:05:39 +0100 X-Lotus-FromDomain: IBMGB To: ots-structs-ftf@omg.org cc: issues@omg.org, juergen@omg.org Message-ID: <80256A25.00478FF1.00@d06mta05.portsmouth.uk.ibm.com> Date: Thu, 5 Apr 2001 14:00:27 +0100 Subject: Activity service Issue: Interposition cannot work as specified Mime-Version: 1.0 Content-Disposition: inline Content-Type: multipart/mixed; Boundary="0__=IgaonwZRUiK3yOOS4MY9n58eGFDY9hbCZYNGvLjKa8Wp1rSDtwbHdbB4" X-UIDL: hg0e9dekd9a,D!!87/!! The FTF is under way so here come a batch of issues. Firstly.... The following section is taken from the Activity srevice specification orbos/2000-06-19. 4.6.5 Interposition When an activity context is propagated, it can be imported by another Activity Service implementation to create a proxy context within the new domain which refers to the exporting domain. This interposition technique (supported by the Current::recreate_context operation) allows the proxy domain to handle the functions of an Activity Coordinator in the importing domain. These coordinators act as subordinate coordinators. Interposition allows cooperating Activity Services to share the responsibility for completing an activity and can be used to minimize the number of network messages sent during the completion process. An interposed coordinator registers as a participant in the activity with the ActivityCoordinator identified in the ActivityContext of the received request; it either registers as an Action, or registers an Action which can then forward Signals to it. The relationships between coordinators in the activity form a tree. The root coordinator is responsible for completing the activity. Subordinate ActivityCoordinators register themselves with their parent as an Action. However, it is not necessary for the subordinate ActivityCoordinator to have the same SignalSet implementations available as at the parent ActivityCoordinator, or for it to know beforehand which SignalSet will be used during Activity completion: the subordinate registers itself as a global Action using the add_global_action method in order to receive any Signal that the parent will send. It is then up to the subordinate to forward these Signals to any appropriate Action that registered with it (including other subordinate coordinators). Since each Signal contains the name of the SignalSet it was generated by, the required mapping of Signal to SignalSet in order to do this is possible. The last paragraph presents a problem in the following scenario: <-------Domain 1---------------> <--------------Domain 2--------------------------------> root subordinate ActivityCoordinator SignalSet ActivityCoordinator Action1 Action2 | | | | | | get_signal() | | | | |---------------->| | | | | | | | | | process_signal() | | | |------------------------------------>|process_signal() | | | | |------------------>| | | | | | | | | | process_signal() | | | |-------------------------------------->| | | | | | | | | | | I've attached an HTML version of the above sketch as it is likely to get mangled by a mail gateway. (See attached file: interpos.html) The problem is that, in domain 2 where there is no SignalSet, how are the Outcomes from Action1 and Action2 supposed to be combined and sent back as a single Outcome to the superior ActivityCoordinator? Further, even if the appropriate SignalSet did exist in domain 2, how could the subordinate ActivityCoordinator get it involved in the request from the superior - the interposed ActivityCoordinator is merely acting as a global Action registered with its superior. I propose the following in order to support interposition: 1. Any signal received by a subordinate ActivityCoordinator be delegated to a SignalSet (assumed to be local since we're using interposition). If the SignalSet is not available, then return a standard Outcome (that also needs to be specified) that indicates that the subordinate ActivityCoordinator is not interested in any further signals from this particular broadcast. 2. Extend the CosActivity::SignalSet interface to provide a set_signal(signal) method to enable a subordinate ActivityCoordinator to indicate to the SignalSet that it will be used only to process the specified Signal (and the Outcomes that are subsequently produced by Actions that receive the Signal) and not to actually produce any Signals. Only the root SignalSet should be producing Signals. An alternative would be to split the SignalSet into 2 objects - the function of 1 object being to produce Signals and the other to combine Outcomes. The down-side of this is the additional complexity it introduces in terms of additional flows between the 2 parts of the SignalSet in the root. Another alternative would be to specialize the SignalSet with a SubordinateSignalSet. Regards...Ian Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com [] interpos.htm From: ian_robinson@uk.ibm.com Received: from d06mta05.portsmouth.uk.ibm.com (d06mta05_cs0 [9.180.35.3]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id QAA99272 for ; Fri, 20 Apr 2001 16:34:26 +0100 Received: by d06mta05.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A34.005586B3 ; Fri, 20 Apr 2001 16:34:10 +0100 X-Lotus-FromDomain: IBMGB To: ots-structs-ftf@omg.org Message-ID: <80256A34.00553216.00@d06mta05.portsmouth.uk.ibm.com> Date: Fri, 20 Apr 2001 16:18:12 +0100 Subject: Re: issue 4250 -- interposition Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: +i+e9SeE!!Q[ on 05/04/2001 15:25:25 Please respond to Juergen Boldt To: issues@emerald.omg.org, ots-structs-ftf@emerald.omg.org cc: Subject: issue 4250 -- Add. Structures for the OTS FTF issue This is issue # 4250 ian_robinson@uk.ibm.com Proposal to support interposition (Active Service spec orbos/2000-06-19) The problem is that, in domain 2 where there is no SignalSet, how are the Outcomes from Action1 and Action2 supposed to be combined and sent back as a single Outcome to the superior ActivityCoordinator? Further, even if the appropriate SignalSet did exist in domain 2, how could the subordinate ActivityCoordinator get it involved in the request from the superior - the interposed ActivityCoordinator is merely acting as a global Action registered with its superior. I propose the following in order to support interposition: 1. Any signal received by a subordinate ActivityCoordinator be delegated to a SignalSet (assumed to be local since we're using interposition). If the SignalSet is not available, then return a standard Outcome (that also needs to be specified) that indicates that the subordinate ActivityCoordinator is not interested in any further signals from this particular broadcast. 2. Extend the CosActivity::SignalSet interface to provide a set_signal(signal) method to enable a subordinate ActivityCoordinator to indicate to the SignalSet that it will be used only to process the specified Signal (and the Outcomes that are subsequently produced by Actions that receive the Signal) and not to actually produce any Signals. Only the root SignalSet should be producing Signals. An alternative would be to split the SignalSet into 2 objects - the function of 1 object being to produce Signals and the other to combine Outcomes. The down-side of this is the additional complexity it introduces in terms of additional flows between the 2 parts of the SignalSet in the root. Another alternative would be to specialize the SignalSet with a SubordinateSignalSet. ================================================================ Juergen Boldt Senior Member of Technical Staff Object Management Group Tel. +1-781 444 0404 ext. 132 250 First Avenue, Suite 201 Fax: +1-781 444 0320 Needham, MA 02494, USA Email: juergen@omg.org URL: www.omg.org ================================================================ From: "Mark Little" To: , References: <80256A34.00553216.00@d06mta05.portsmouth.uk.ibm.com> Subject: Re: issue 4250 -- interposition Date: Tue, 24 Apr 2001 10:17:45 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 3ePe9ja:e9X*g!!MF(e9 > A SignalSet on an interposed node needs only to collate the Outcomes of > Actions registered locally; it doesn't need to produce Signals since the > Signals are only produced by the SignalSet at the root. That's not necessarily true. Take the case of a prepare that is sent to a subordinate coordinator, which then sends it to locally registered participants. If one of those participants refuses to prepare, the root coordinator is only going to send the rollback response. A subordinate coordinator, since it has the same logic as the root, can optimise this and do the rollback locally, before returning a roll back response. Do we want to preclude this kind of optimisation? > In order to return a collated response to its superior, the interposed > SignalSet needs to be able to produce an Outcome for every Signal it > receives from its superior. This requires a change to the description of > the SignalSet::get_outcome() method description. I propose that the > get_outcome() method description should be changed as follows: > "Returns a final or an intermediate outcome determined by the SignalSet; > it is valid for this value to be nil. The ChildLifetime SignalSet returns > nil." I disagree. There is a lot of semantic knowledge that can be obtained from knowing that get_outcome always returns the final state of the SignalSet. Adding a get_current_outcome would accomplish the same thing, and retain that knowledge. The SignalSet is a state-machine object. Currently we assume it always starts from state 0. However, we could enable it to start from any arbitrary point (as long as, once started, it cannot be re-started, i.e., it cannot be made to go directly to some other point in the state machine.) > As a consequence, this method would no longer throw the SignalSetActive > exception. This exception would no longer be needed. > I have removed the reference to the Synchronization SignalSet from the > description above, since a Synchronization SignalSet on an interposed node > should return the org.omg.preCompletionFailed outcome (or whatever it gets > called if Issue #4258 is accepted) if any of the locally registered Actions > return this. We can address this when we address 4258. Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 From: ian_robinson@uk.ibm.com Received: from d06mta05.portsmouth.uk.ibm.com (d06mta05_cs0 [9.180.35.3]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id AAA234294; Wed, 25 Apr 2001 00:09:01 +0100 Received: by d06mta05.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A38.007F271C ; Wed, 25 Apr 2001 00:08:50 +0100 X-Lotus-FromDomain: IBMGB To: "Mark Little" cc: ots-structs-ftf@omg.org Message-ID: <80256A38.007F2601.00@d06mta05.portsmouth.uk.ibm.com> Date: Tue, 24 Apr 2001 20:26:18 +0100 Subject: Re: issue 4250 -- interposition Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: "T_!!~[]d9@#)!!j?8!! >> A SignalSet on an interposed node needs only to collate the Outcomes of >> Actions registered locally; it doesn't need to produce Signals since the >> Signals are only produced by the SignalSet at the root. > > That's not necessarily true. Take the case of a prepare that is sent to a > subordinate coordinator, which then sends it to locally registered > participants. If one of those participants refuses to prepare, the root > coordinator is only going to send the rollback response. A subordinate > coordinator, since it has the same logic as the root, can optimise this and > do the rollback locally, before returning a roll back response. Do we want > to preclude this kind of optimisation? > I agree that we don't want to preclude this. The statement was a lead-in to the next paragraph.... >> In order to return a collated response to its superior, the interposed >> SignalSet needs to be able to produce an Outcome for every Signal it >> receives from its superior. This requires a change to the description of >> the SignalSet::get_outcome() method description. I propose that the >> get_outcome() method description should be changed as follows: >> "Returns a final or an intermediate outcome determined by the SignalSet; >> it is valid for this value to be nil. The ChildLifetime SignalSet returns >> nil." > > I disagree. There is a lot of semantic knowledge that can be obtained from > knowing that get_outcome always returns the final state of the SignalSet. > Adding a get_current_outcome would accomplish the same thing, and retain > that knowledge. > An additional get_current_outcome would be fine. Regards...Ian Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from d06lmsgate-2.uk.ibm.com (195.212.29.2) by hobbit.omg.org asmtp(1.0) id 11194; Fri, 11 May 2001 22:47:26 -0400 (EDT) Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id DAA15318 for ; Sat, 12 May 2001 03:27:03 +0100 From: ian_robinson@uk.ibm.com Received: from d06mta05.portsmouth.uk.ibm.com (d06mta05_cs0 [9.180.35.3]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.96) with SMTP id DAA288078 for ; Sat, 12 May 2001 03:42:43 +0100 Received: by d06mta05.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A4A.000EE51D ; Sat, 12 May 2001 03:42:41 +0100 X-Lotus-FromDomain: IBMGB To: issues@omg.org Message-ID: <80256A49.00497760.00@d06mta05.portsmouth.uk.ibm.com> Date: Fri, 11 May 2001 12:12:21 +0100 Subject: Re: issue 4250 -- interposition Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: [-O!!Ohdd9abB!!4n#"! Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com ---------------------- Forwarded by Ian Robinson/UK/IBM on 11/05/2001 12:11 --------------------------- Ian Robinson 24/04/2001 20:26 To: "Mark Little" cc: ots-structs-ftf@omg.org From: Ian Robinson/UK/IBM@IBMGB Subject: Re: issue 4250 -- interposition (Document link: Ian Robinson) >> A SignalSet on an interposed node needs only to collate the Outcomes of >> Actions registered locally; it doesn't need to produce Signals since the >> Signals are only produced by the SignalSet at the root. > > That's not necessarily true. Take the case of a prepare that is sent to a > subordinate coordinator, which then sends it to locally registered > participants. If one of those participants refuses to prepare, the root > coordinator is only going to send the rollback response. A subordinate > coordinator, since it has the same logic as the root, can optimise this and > do the rollback locally, before returning a roll back response. Do we want > to preclude this kind of optimisation? > I agree that we don't want to preclude this. The statement was a lead-in to the next paragraph.... >> In order to return a collated response to its superior, the interposed >> SignalSet needs to be able to produce an Outcome for every Signal it >> receives from its superior. This requires a change to the description of >> the SignalSet::get_outcome() method description. I propose that the >> get_outcome() method description should be changed as follows: >> "Returns a final or an intermediate outcome determined by the SignalSet; >> it is valid for this value to be nil. The ChildLifetime SignalSet returns >> nil." > > I disagree. There is a lot of semantic knowledge that can be obtained from > knowing that get_outcome always returns the final state of the SignalSet. > Adding a get_current_outcome would accomplish the same thing, and retain > that knowledge. > An additional get_current_outcome would be fine. Regards...Ian Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com Importance: Normal Subject: Issue 4250: proposal To: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Mon, 16 Jul 2001 22:33:20 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 17/07/2001 09:05:04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: /B&!!5(Xd9iVHe9VeBe9 Proposal for resolution of 4250: A domain that contains an interposed, subordinate ActivityCoordinator can support Actions registering at that subordinate ActivityCoordinator with an interest in, say, SignalSet "X". The subordinate ActivityCoordinator must use a specialised implementation of X that supports a SubordinateSignalSet interface. The SubordinateSignalSet interface is added to CosActivity module as follows: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ interface Subordinate SignalSet : SignalSet { void set_signal (in Signal signal); Outcome get_current_outcome() raises SignalSetInactive; }; set_signal Sets the Signal to be sent to the Action objects registered for this SubordinateSignalSet. This method is called by a subordinate ActivityCoordinator when it receives a Signal from its superior. The subordinate ActivityCoordinator distributes this Signal to each appropriate Action and passes each Action Outcome back to the SubodinateSignalSet via the set_response method. The SubordinateSignalSet produces a combined Outcome for the set Signal and this is returned by the subordinate ActivityCoordinator to its superior. Any system exceptions raised by the SubordinateSignalSet should be converted to an ActionError by the subordinate ActivityCoordinator. get_current_outcome Returns an intermediate outcome of the SubordinateSignalSet. This may be called after the processing of each Signal and is used by a subordinate ActivityCoordinator to obtain an Outcome to return to its superior in response to a received Signal. If the SignalSet has not been initialized, for example by a call to set_signal, then the SignalSetInactive exception will be thrown. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The SignalSetInactive Exception description should be changed to the following: The SignalSetInactive exception is raised by the SignalSet if an attempt is made to use the SignalSet without having first called get_signal or set_signal. The third paragraph of "2.2.10 Interposition" refers to the use of global actions as a means to implement interposition and should be changed to say the following: A subordinate ActivityCoordinators registers itself with its parent as an Action, with an interest in the Synchronization SignalSet. An Action may be subsequently registered with the subordinate ActivityCoordinator with an interest in a particular SignalSet that is available to the root ActivityCoordinator. The subordinate ActivityCoordinator must have a SubordinateSignalSet implementation available to it and should register an Action with an interest in a SignalSet of the same name with its superior ActivityCoordinator. When the subordinate ActivityCoordinator receives a Signal from its superior it calls the set_signal method on the SubordinateSignalSet passing the Signal as a parameter. The subordinate must then forward the Signal to any appropriate Action that registered with it (including other subordinate ActivityCoordinators) and pass each Outcome received to the SubordinateSignalSet. The role of the SubordinateSignalSet is to combine the Outcomes produced into a single Outcome that can be returned to the superior by the subordinate ActivityCoordinator. Once a subordinate ActivityCoordinator has completed distributing a received Signal, it should ask the SubordinateSignalSet for the next signal in case the SubordinateSignalSet is able to produce another Signal, independently of any superior SignalSet, which the subordinate ActivityCoordinator should distribute to any appropriate Actions. Any such Signals are produced as a performance optimization by the SubordinateSignalSet and must not change the Outcome that was produced as a result of the Signal received from the superior. Regards...Ian Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com From: "Mark Little" To: "XOTS" Subject: FTF meeting summary Date: Wed, 18 Jul 2001 10:05:44 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Filter-Version: 2.1 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *%D!!CL[d9H0jd9D]:!! Just a quick note to report on the meeting we had at Danvers. We managed to work through all of the issues that were reported prior to Danvers, though some have come up since. A brief summary of the issues we discussed, and the resolutions follows (the individuals who will write up the final proposed resolutions are also indicated). Proposal for 4250: to add a subordinate signalset with the set_signal method. Have get_current_outcome to return the current outcome from the subordinate. Interposed coordinators create instances of the SubordinateSignalSet and registers them. An appropriate Action is also created and registered with the root, and this drives the subordinate. The subordinate can generate its own Signals if, for example, it knows that the subtree is going to have to do X (e.g., roll back) anyway, so why wait for the root to send the same Signal? The subordinate can also be a superset of the root (i.e., can generate more Signals than the root ever would), and can send the outcome back up the tree in an implementation specific manner, i.e., synchronously or asynchronously. [Ian Robinson to write up.]