Hi Gerald, > || Gerald - I've just received your posting today (8 July) || > || Not read it yet though ... || I've read it now! Excellent!! Your thoughts have taken you to almost exactly the same destination as mine ... even down to exactly the same (!) user-APIs for the CALL channel calls and accepts ... and to the notion (obvious, I guess, in retrospect) of *variant* CALL channels. This is good evidence that there is something useful and right here ... ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) Your criteria: > 1. CALL channels are higher level channels than the low-level channels. CALL > channels specify public methods for the client processes and methods for the > server processes. The read() and write() methods are too restrictive at this > higher level. Yes. But the primitive channels are still powerful on their own and, for many circumstances, are all we need. But CALL channels *are* a higher level abstraction (one of, I fancy, several) and are a big win (ease of use, semantics and, possibly, lighter implementation) in the many circumstances where they are appropriate. > 2. A CALL channel should extend or implement, (1) a Channel interface that > tells that the CALL channel is a channel, (2) a CallService interface that > specifies the methods for the client and (3) an AcceptService interface that > specifies the methods for the server. Yes. I think we both have this - although mine only *contains* a channel rather than *extends* it. See nasty technical matter below. The user doesn't suffer though. > 3. A CALL channel is a design pattern of low-level channels. One should be > able to create its own CALL channel. Developing CALL channels must be easy. Yes. > I belief that editing low-level channels is too complex for the programmer > and low-level channels must be seen as primitive objects. In the many circumstances where CALLs are appropriate, using ordinary channels is too low-level. > 4. CALL channels must be thread-safe with using channels and without using > monitors. Yes. > 5. The server process implements the methods that can be called by the > client. The CALL channel redirects these calls from the client(s) to the > server via low-level channels. Last sentence - not necessarilly. The CALL channel can just invoke the call directly on the server. That's been my approach ... and it *may* have an impact for your next point? > 6. A CALL channel should support remote channels. Yes. In your posting today: > Although your call channel does not support remote channels it is fast and > easy. You are miles ahead in the distribution of channels between processors. At Kent, we have something that just about works for distributed JCSP channels using Java RMI. The `distributed' channel just sits in one processor (usually the inputting end so that ALTing is more efficient) and the other ends just RMI to it. This works most of the time. But there are some nasty problems you can get into when you use RMI lots of times. These seem to be to do with resource limits (e.g. for creating sockets). I fear that RMI may be a bit inefficient at the moment ... but this should change given time. For remote versions of CALL channels, the RMI trick we use for channels should work just the same. We just put the whole CALL channel object at the accepting end and RMI to it from the caller(s). But the ideas you described -- of sandwiching your TCP/IP driven CALL channel between mine -- may be lots more efficient! > ButtonCallChannel inherits CallChannel and CallChannel inherits Channel. > This would automatically make the ButtonCallChannel ready for alting on an > ALT. Here, inheritance works. :-() Yes! The reason it's not working for JCSP is that it's distinguishing between Alting channels and non-Alting channels and between the 1-1, many-1, 1-many and many-many versions. It would be easy to dispense with these varieties and just have channels that were Alting and many-many. But I like the explicit declaration of these varieties (for semantic reasons) and the reduced overheads possible when you don't need all the facilities. Semantically, there is also a big difference between the 1-1 channel and any `many' variety: the former is deterministic whereas the latter are not (for example, many-1 channels are akin to ALTing). The other technical reason why inheritance fails is that the JCSP Guard is an abstract class rather than an interface. The Guard abstract class only contains method headers (enable/disable, needed internally to manage the ALT). JCSP users don't need to know about them. So these methods cannot be public or protected. Nor can they be private. They have to be package-visible. That means they can't be in a Java interface ... which can only contain *public* methods for some reason ... which is why Guard is an abstract class. So, my One2OneCallChannel has to *extend* AltingChannelAccept (rather than *implement* it, which is what it actually does) and, then, it can't *extend* One2OneChannel as well. Stuffed! Still One2OneButtonChannel would extend One2OneCallChannel ... so I can show off to my OO friends ;-) Cheers, Peter.