FAST error handling and our plugin interface
jaltman at secure-endpoints.com
Thu Mar 5 11:25:01 EST 2009
Sam Hartman wrote:
> However we don't have that plugin interface today and it is desirable
> to keep things working with the current plugins. So, my plan for the
> current interface is to continue doing what we're doing in the
> non-FAST case.
For clarity sake, just how many plugins are we talking about?
When the plugin interface was being designed we knew that it was not a
complete interface and it was exposed with the expectation that things
might have to change in the future.
My failing to pass in the two separate sets of padata to the plugins,
each plugin is going to have to replicate the logic to separate the
hints from the actual error data.
I agree with you. The hack of re-encoding the pa-data as typed-data so
that the existing plug-ins can accept it in the e_data field is ugly
and potentially confusing to future implementers.
If we believe that we know most of the plug-in authors, then I would
advise to revise the plug-in interface to make life easier for everyone
going forward. The old interface should be recognized and either have
a "deprecated" error returned to them or perhaps take the code that you
were going to use to translate the padata to the typed-data and instead
of using it everywhere, just use it as a wrapper to provide data to
plug-ins that support the old interface.
Documentation describing how to convert a plug-in from the old interface
to the new interface could be written including how to detect at compile
time which interface is available so that the plug-in can be built
I'm not going to be putting any resources behind any of this so feel
free to toss this e-mail into the trash and forget it was ever written.
Just my $0.00 cents.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090305/f75f3ea2/attachment.bin
More information about the krbdev