RE: Channels versus Methods

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

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.