Subject: JGSS Class Struggle: comment and reflection

From: Michael Smith <[email-masked]>
Date: Thu, 04 Nov 1999 09:52:38 -0500

[comment]

At 03:48 PM 11/3/99 -0800, Joe wrote:

>If Sun or any other vendor goes against the specification and implements a
>concrete GSSManager that is final then there is a problem.   Then again
>there are many other areas in which a non-conforming implementation can
>inhibit interoperability.

Right; but this is an area where a non-conforming (local) implementation
can also inhibit an app from using its own (conforming) implementation, 
because any implementation that's loaded has to subclass the local 
one. That's if GSSManager is a class. If it's an interface no such 
problem arises. 

[reflection]

I've been meditating on this discussion. I think what may be 
causing a problem for us is a failure to draw a sufficiently 
clear distinction between Java-the-language and 
Java-the-environment. Java is both, and in my opinion that's
a Good Thing (at least so far). But I think it's useful 
to keep track of which one you're talking about in a 
particular context. 

Language bindings, as the name suggests, relate to 
Java-the-language. What we have to bind is an 
"application program _interface_", and the lexical overlap
between this phrase and the Java notion of an Interface is 
not an accident. Java Interfaces were designed to do precisely 
the kind of job we have before us -- specifying a language 
binding for GSS-API, accent on the 'I'. 

What Jack and Mayank are trying to address by making GSSManager
a class and including a getInstance() method is a quite different
problem, relating to environment configuration and resource 
discovery. I don't object to addressing that problem, but I 
think it's unwise to mix it up with the language binding -- 
particularly if we do so in a way that may end up inhibiting 
the work of implementers. 

Note that this WG, to the best of my knowledge, has never 
taken an explicit decision to address issues of environment
configuration and resource discovery, either in general or in 
any other specific context, and I should think that 
we ought to have a liminal discussion of whether or not 
such issues fall within our scope before we proceed down 
that path. Wrt Java, I personally think it would be useful 
for us to do something in this area, and I'd like to 
contribute. But we should keep it distinct from the language 
binding. 

--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]