Subject: Re: JGSS follow-up

From: Michael Smith <[email-masked]>
Date: Sun, 04 Apr 1999 05:01:37 -0400

At 11:41 AM 3/31/99 -0800, "Jack Kabat" <[email-masked]> wrote:
>Hello Everyone,
>
>
>As a result of the recent discussions of JGSS bindings, Mayank and I are
>planning to modify the Java GSS bindings in the following manner:
>
>Addition of interfaces to the specification:
>Our plan is to start with the addition of 3 interfaces, one for each of
>GSSName, GSSCredential, and GSSContext. These should be sufficient to
>encapsulate all the mechanism specific functionality.  

We seem to have returned here to a confusion (conflation?) which 
plagued this discussion at an earlier stage -- namely that between
an "implementation" and a "mechanism". The point of specifying
JGSS as a set of Java interfaces is not to provide mechanism 
independence -- the abstract semantics of GSS itself, after considerable
effort in this WG, does that -- but to provide implementation 
independence. An implementation, as has been observed previously, 
may contain one or many mechanisms, depending on local requirements. 

>The interfaces will utilize some of the existing concrete classes such as
>Oid, MessageProp, ChannelBindings, and GSSException. 

This seems half-hearted. One of the virtues of interfaces (as opposed
to classes) is that they provide for multiple inheritance. This advantage
is lost if implementers have to extend the concrete classes 
(MessageProp, ChannelBinding, etc.) My impression of the Minneapolis
consensus was that the whole API should be specified as interfaces; 
why do it halfway? 

>A question that arises is, for an implementation to be conformant to the
>specification, does it need to implement both concrete classes and
>interfaces? I think the answer should be yes, it needs to implement both.

This point might usefully be elaborated a bit further -- at least I 
don't quite understand it. An interface clearly needs to be implemented
before it's any use -- so far, so good -- but a concrete class
_is_ an implementation, in the sense that there's real code behind
it. Unless Jack means that the concrete classes would, in effect, 
just have no-op methods and that any real implementation would 
have to extend these in order to provide any actual functionality?
In which case there seems to be no point in having concrete classes 
at all; the flexibility of interfaces is lost, without any offsetting
gain in functionality. A lose-lose situation. But perhaps I've 
misunderstood the idea here? 

--Michael Smith
  [email-masked]

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]