Re: Proposed PRF changes to address Ken's comments
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed PRF changes to address Ken's comments



On Mon, Jun 27, 2005 at 11:33:48AM -0400, Jeffrey Altman wrote:
> Seema Malkani wrote:
> > To answer Ken's question :
> > 
> > Adding a new method to a standardized interface will break existing
> > applications. This means all classes that implement GSSContext interface
> > will now need to add the new method. All implementations of Java GSS
> > will NOT compile until the new method is added.
> > 
> > Abstract classes don't have such a problem, since you can provide a
> > default (possibly empty) implementation, and existing implementations
> > will not break. It is easier to evolve an abstract class than to evolve
> > an interface. Since GSSContext was defined to be an interface, we cannot
> > change it.
> > 
> > Alternatives ?
> > 
> > We can possibly add the new method to GSSManager class, which is an
> > abstract class. This class serves as a factory for three GSS interfaces:
> > GSSName, GSSCredential, and GSSContext. The new method will have to be
> > invoked after the GSSContext has been established.
> 
> Seema:
> 
> This will definitely be a much more generic issue for Java GSS support
> than just the PRF.  There are a number of new methods that the work of
> this group will require moving forward.   Adding them all to the
> GSSManager class seems like an inappropriate thing to do.  Even if we
> hold off defining a Java binding for PRF and wait for the majority of
> this group's work to complete, we will still be faced with this issue.
> I think we need to address the question of extensibility for the Java
> bindings.   It would be unfortunate if everytime new GSS functionality
> was defined the interfaces implementing one or more of the classes had
> to be replaced.

I propose removing the Java bindings from the PRF I-D and resolving this
problem separately.  No, I don't like this proposal, but it's either
that or wait to resolve the Java bindings extensibility issue first.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.