On 30-Jan-2004 Scott wrote:
>     Philip,
> 
>     I really love the idea of IKC, and although I've been a big-time fan
> of POE for several years now I never really dug into the IKC components 
> until recently.  And although I think its great such a thing exists, I 
> really think it could be approached a *lot* better.  Not only from an 
> API standpoint (eh, create_ikc_server?  I realize 
> POE::Component::IKC::Server->spawn() 

IKC is a bit of a kluge, yes. It even says so in the docs :) I wanted
something that worked and I wanted to explore the problem space.  I didn't
have a lot of time to put into it.  IKC works and works relatively well,
if slow (as you point out).  I've used it to write application servers for
several e-commerce sites I've created.  So it's stable.

> works but still, how do I 
> authenticate?  Or just let anything connect?  eep!)

All security was deliberatly left out.  It would have been so easy to get
it wrong that I thought it better to leave it to implementers to do.  The
problem with security for RMI is not easy : look at the mess the that SOAP
is.

If I had to implement security, I'd overload IKC::Channel.

I should also point out that Stem, which is POE + IKC + a few other bits,
also doesn't deal with security.  I talked with Uri about this and his
point was that if you don't trust your network, use an SSL tunnel.  And if
you don't trust other local users, you should run your application on
another computer.

>     So here is what I propose, as I have noticed the project seems 
> fairly stale - last updates well over a year ago.  If I was to redesign 
> POE::Component::IKC, from the ground up, 

I've been dreaming of doing this for years.  I'd love to redo the
negotiation protocol, maybe borrowing from BEEP, or something different. 
And it needs to be more modular and overloadable.  As the saying goes "plan
to throw one away".  But I don't have the time.  Or rather, IKC does
pretty much everything I need, and no one is going to pay me to redo it.

If you want to work on IKC 2.0, I have no objections.  In fact I'll gladly
contribute as a kibizer, idea-fairy, coder, debuger and chearing squad.

> using the same core namespace (::IKC) but different individual
> component namespaces as to not break backward compatability, would you
> be willing to free up the ::IKC namespace on CPAN?

You mean withdraw my IKC packages?  If so, unlikely, but it depends on
how the new IKC turns out.  If at all possible, I'd like a drop in
replacement (maybe with a compatibility layer) for IKC.

So maybe you/we should put next version in ::IKC2?  IKC is currently
version 0.14.  I want to change the negociation protocol (at least) and
call it 1.0 at some point.  A major rewrite would be IKC2.  

BTW, have you read the FUTUR file that comes with IKC?

Hoping to hear your ideas,

-Philip