Doug, KCP doesn't show up in BFAV yet, hence this heads up. This
approves almost all the outstanding KCP stuff.

To business - I really like the way the new deprecation system works
out. People deprecating all sorts of protocols should really be using
this. Of course for every deprecation we do, eventually, we'll have to
remove the deprecated code - maybe we should do this at the beginning of
each alpha?

A small deployment question - I got a deprecation wb at 84, proceeded,
and all was fine. This cause me to think something that somewhat related
to the above - maybe we should have a preference to decide whether
deprecation should be active or not, and set it to false when we want it
to work quietly? this could be used to solve this small annoyance, but
even better, we could set to off in released images, and to on in
alpha/beta/gamma images. This would hide ugliness from end users, but
not from the rest of us.

What do you think?

BTW, why did you add the *Deprecated methods?

A note about my review - I didn't check all the code, I only understood
the design idea and sampled the implementation to get a taste. IOW, I
think we have this process pretty well optimized, and it's not taking me
a long time. So we can run with this as quick as the KCP team wants, and
I wont mind doing the approvals more frequently, if you tell me when you
have a logical part completed.

One place where I think things should be done differently (we talked
about this before -)
64. The way HTTPSocket is changed makes the dependency on GifReadWriter
dynamic/hidden from analysis, but the methods are still ineffective when
the media handling classes are missing. I think those are exactly the
case where a class extension would be better - if the media code is
removed, so should the methods that depend on it. I'm less sure about
Form, maybe its media sampling code should be extracted to some
ImageReaderWriter too?

Everything else, that is, 67, 68, 69, 70, 71, 76, 78, 83, 84, 85, 87,
88, 90 - approved.

Daniel