projects / unix-history / blame
| Commit | Line | Data |
|---|---|---|
| d626f7a5 C |
1 | This new top level directory is intended to provide routines which |
| 2 | implement the mappings defined for RO-Notation MACROS BIND and UNBIND | |
| 3 | onto ACSE. | |
| 4 | ||
| 5 | The mappings of the BIND and UNBIND macros onto RTSE are NOT provided. | |
| 6 | ||
| 7 | The routines provided here are extensions of the code previously included in | |
| 8 | the dsap/net library specifically for the directory. | |
| 9 | ||
| 10 | ||
| 11 | ||
| 12 | RO-NOTATION BIND and UNBIND macros can map either onto ACSE or onto RTSE | |
| 13 | ||
| 14 | BIND/UNBIND operations need not report outcome if they do, then it follows | |
| 15 | the single data value form. | |
| 16 | ||
| 17 | BIND maps to A-ASSOCIATE | |
| 18 | UNBIND maps to A-RELEASE | |
| 19 | ||
| 20 | BIND success => | |
| 21 | accepted, user information = result if any | |
| 22 | ||
| 23 | Nothing is said about what happens when an A-ASSOCIATE is well-formed | |
| 24 | as such, but not as a BIND (which errors are used??) | |
| 25 | ||
| 26 | An UNBIND operation may disrupt operations - this is the only disruption | |
| 27 | of service. | |
| 28 | ||
| 29 | If BIND operations collide, then 2 application contexts are established. | |
| 30 | BIND unsuccessful | |
| 31 | rejected (permanent), user information = error if any | |
| 32 | ||
| 33 | Everything looks OK the way it has been done, except for the separation | |
| 34 | of the RO-BIND, RO-UNBIND implementation from the rosap library. | |
| 35 | ||
| 36 | **** | |
| 37 | ||
| 38 | Having finally seen a copy of the standard for remote operations | |
| 39 | notation i am even more strongly convinced that ISODE should provide | |
| 40 | an interface to support RO-BIND and RO-UNBIND. | |
| 41 | ||
| 42 | As far as quipu is concerned the changes required are structural, and | |
| 43 | _should_ (although this is rarely completely the case) be achievable | |
| 44 | without introducing any new errors. | |
| 45 | ||
| 46 | Eventually, this code should be moved into the rosap library or a | |
| 47 | library of its own. Attempts have been made to keep close to the | |
| 48 | ISODE style used in rosap to allow this to be accomplished more easily. | |
| 49 | Only the mapping of RO-BIND and RO-UNBIND for ROSE using ACSE is | |
| 50 | tackled, a full solution requires a parallel library for the mapping | |
| 51 | onto RTSE. | |
| 52 | ||
| 53 | The ABSTRACT-BIND and ABSTRACT-UNBIND macros have a defined mapping onto | |
| 54 | ACSE primitives. Currently ISODE does not directly support the use of | |
| 55 | ABSTRACT-BIND and ABSTRACT-UNBIND, but leaves it to the application | |
| 56 | programmer to implement the mapping. Quipu currently implements such | |
| 57 | a mapping, but with poor abstraction. | |
| 58 | ||
| 59 | An interface which supports the RO-BIND and RO-UNBIND operations as an | |
| 60 | ACSE-user should be provided as soon as possible by ISODE for several | |
| 61 | reasons: | |
| 62 | 1) Tidying up quipu code | |
| 63 | 2) Easier implementation of other ASE's | |
| 64 | 3) Possible incorporation of BIND, UNBIND and perhaps | |
| 65 | even APPLICATION CONTEXT into rosy. | |
| 66 | ||
| 67 | The motivation here is 1), but ISODE styles will be followed where | |
| 68 | this is simple and appropriate so that 2) and 3) are made easier | |
| 69 | objectives. (Aside i am assuming that a suitable solution to the | |
| 70 | ACSE-user vs. RTSE-user problem is to have separate libraries and | |
| 71 | separate include files accepting the smallish costs of duplication | |
| 72 | between them - this has the added benefit that the BIND user selects | |
| 73 | the underlying services by selecting the right library which has the | |
| 74 | additional benefit that the RoSetService no longer needs to be visible | |
| 75 | in the application using RO-BIND.) | |
| 76 | ||
| 77 | Use of ACSE as described in the ISODE manual is provided by the | |
| 78 | routines: | |
| 79 | AcAsynAssocRequest() A-ASSOCIATE.REQUEST | |
| 80 | AcInit() A-ASSOCIATE.INDICATION | |
| 81 | AcAssocResponse() A-ASSOCIATE.RESPONSE | |
| 82 | AcAsynRetryRequest() A-ASSOCIATE.CONFIRMATION | |
| 83 | AcAsynRetryNext() A-ASSOCIATE.CONFIRMATION | |
| 84 | AcRelRequest() A-RELEASE.REQUEST | |
| 85 | (*)AcFINISHser() A-RELEASE.INDICATION | |
| 86 | AcRelResponse() A-RELEASE.RESPONSE | |
| 87 | AcRelRetry() A-RELEASE.CONFIRMATION | |
| 88 | ||
| 89 | (*) The routine AcFINISHser is called implicitly by RoWaitRequest() | |
| 90 | having been selected at the ACSE level by a call to RoSetService() | |
| 91 | with value RoPService. This routine should be replaced with an extended | |
| 92 | routine (eg RoUNBINDser which would call AcFINSIHser) so that an | |
| 93 | RO-UNBIND ARGUMENT can be looked for and decoded if present. (Presumably, | |
| 94 | a similar change would be necessary to support the RTSE equivalent). | |
| 95 | I made have made misguided comments in my previous message about | |
| 96 | drastic changes to rosap, this was due to misunderstandings on my part. | |
| 97 | ||
| 98 | Since no argument (or results or errors for that matter) are used in | |
| 99 | the UNBIND of the X.500 protocols this problem can safely be ignored | |
| 100 | for the moment. | |
| 101 | ||
| 102 | One question i haven't been able to satisfy myself about is whether | |
| 103 | the implementation of RO-BIND should return RoSAPindications or its | |
| 104 | own definition eg RoBINDindications. I don't want to touch rosap itself | |
| 105 | at the moment and so have implemented the second. | |
| 106 | ||
| 107 | A straightforward use of the ISODE acsap routines can be made to provide | |
| 108 | an ABSTRACT-BIND/ABSTRACT-UNBIND interface with the following routines: | |
| 109 | ||
| 110 | RoAsynBindRequest() | |
| 111 | Encodes bind argument | |
| 112 | Calls AcAsynAssocRequest() | |
| 113 | Maps AcSAPindications to RoBINDindications | |
| 114 | Calls RoSetService() | |
| 115 | If completed: Decodes bind result or bind error | |
| 116 | RoBindInit() | |
| 117 | Calls AcInit() | |
| 118 | Maps AcSAPindications to RoBINDindications | |
| 119 | Calls RoSetService() | |
| 120 | Decodes bind argument | |
| 121 | RoBindResponse() | |
| 122 | Encodes bind result or bind error | |
| 123 | Calls AcAssocResponse() | |
| 124 | Maps AcSAPindications to RoBINDindications | |
| 125 | RoBindRetryRequest() | |
| 126 | Selects either AcAsynRetryRequest() or AcAsynNextRequest() | |
| 127 | Maps AcSAPindications to RoBINDindications | |
| 128 | If completed: Decodes bind result or bind error | |
| 129 | RoUnBindRequest() | |
| 130 | Encodes unbind argument | |
| 131 | Calls AcRelRequest() | |
| 132 | Maps AcSAPindications to RoBINDindications | |
| 133 | If completed: Decodes unbind result or unbind error | |
| 134 | RoUnBindResponse() | |
| 135 | Encodes unbind result or unbind error | |
| 136 | Calls AcRelResponse() | |
| 137 | Maps AcSAPindications to RoBINDindications | |
| 138 | RoUnBindRetryRequest() | |
| 139 | Calls AcRelRetryRequest() | |
| 140 | Maps AcSAPindications to RoBINDindications | |
| 141 | If completed: Decodes unbind result or unbind error | |
| 142 | ||
| 143 | All arguments, except the presentation element representing the user data, | |
| 144 | and the replacement of the AcSAPindication parameter by an RoBINDindications | |
| 145 | parameter are passed straight through. | |
| 146 | ||
| 147 | Other questions i am less than sure about are: | |
| 148 | ||
| 149 | Should rob use the rosap log?? I think it should. | |
| 150 | ||
| 151 | Should RoBINDindication be a RoSAPindication?? Not sure. | |
| 152 | ||
| 153 | Should rob define separate (non-ACSE) definitions?? Yes, but its costly. | |
| 154 | This would allow the definition of RoSAPstart, RoSAPconnect, ... for | |
| 155 | either of ACSE or RTSE, completely obscuring the underlying services from | |
| 156 | the user of the RO-notation. This is what we want eventually and one reason | |
| 157 | for pulling this stuff out of the bottom of the dsap library. |