evans@decvaxdec.com (Marc Evans) (05/30/90)
Now that OSF has announced that it will use Decorum, will this decision impact
the future directions of the ISIS project? It seems to me that they overlap to
some degree, and therefore maybe ISIS would want to take advantage of some of
the development which is going into Decorum. However, being the type of
research
project ISIS is, maybe it will want to continue using the techniques it already
does for IPC and other overlap areas.
- Marc - Just a little curious...
===========================================================================
Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)635-8876
Unix and X Software Contractor | 21 Hinds Ln, Pelham, NH 03076
===========================================================================wunder@hp-ses.SDE.HP.COM (Walter Underwood) (05/31/90)
It would be nice to see Isis using NDR and a stub generator instead of the printf-like specs. That would allow specifications for Isis services (or are they dialogues?), and compile-time checking for the formats. wunder
ken@gvax.cs.cornell.edu (Ken Birman) (06/04/90)
In article <65@decvax.decvax.dec.com.UUCP> evans@decvax.DEC.COM writes: >Now that OSF has announced that it will use Decorum, will this decision impact >the future directions of the ISIS project? ... etc Our effort has a commercial side as well as a research side and IDS will certainly be looking very hard at Decorum. There are actually fewer areas of overlap then you may think, though, in that ISIS is really a fairly conventional user of the sorts of services Decorum provides (ie time service, name service, file system) and does not itself define many of these sorts of services in the present release. As you may be aware, we actually submitted ISIS under the OSF DCE RFT. OSF looked hard at ISIS and basically concluded that it lives at a higher level of the system than the DCE is aimed at, but on the other hand that something like ISIS may belong in the OSF offerings in the future. We intend to maintain a dialog with them, and they have indicated that they plan to do so with us. My guess is that there will be some sort of an RFT in the future under which systems like ISIS would fit, and that we will resubmit the system then. I have been very impressed by the technical strength of the OSF crowd. With respect to ISIS, they know exactly what we have and have made a very reasonable (if conservative) decision to postpone these issues until process-group technologies mature. At the same time, Decorum apparently does anticipate the need to support process groups in the future. As for specific changes to ISIS to make use of Decorum, though, we'll need to wait and see how best to do this. For example, I wouldn't like to get into a situation where ISIS under Decorum can't talk to ISIS under the UI systems of the future! On the other hand, we will certainly "port" ISIS to Decorum at some point (or IDS will), and will try to do this in the least intrusive way possible. Decorum is, realistically, only one of several exciting new systems -- Chorus being another, and the system that SUN is (rumored) to be developing being a third... Ken
ken@gvax.cs.cornell.edu (Ken Birman) (06/04/90)
In article <6110003@hp-ses.SDE.HP.COM> wunder@hp-ses.SDE.HP.COM (Walter Underwood) writes: >It would be nice to see Isis using NDR and a stub generator instead of >the printf-like specs. That would allow specifications for Isis >services (or are they dialogues?), and compile-time checking for the >formats. > I agree; this would be a nice improvement. My inclination would be to support a %n format type, though, and perhaps a %x format for those of you who are fond of XDR. My difficulty with stub generation has always related to the way that multiple replies are returned. One recent idea was to allow the sender of a broadcast to supply a "collator" function; it would be called on each received reply and would indicate if it wants ISIS to wait for "more replies". Another possibility is to imbed this in the function call itself; I recently saw a language spec for a system called FLAME (Mehdi Jazayeri of hplabs was the first author) and it adopts this approach. A third approach is the one that Marc Shapiro uses in SOS, with stubs that are actually defined as part of the service (part of its interface, in fact) and hence can include some fairly fancy logic... Assuming that we went with the first ("callback") style of reply collection, would this and a %n format permit reasonable stub generation for process-group based services? Ken