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.