otisg wrote:
k2d2 looks like a concrete implementation of an API that is
defined within the k2d2 framework itself. The implementation
allows generic components to be assembled in a chain, and
connected with blocking queues. I guess this is where the
concreteness of k2d2 shows - it is more than just the API. However, Chain also has some concrete implementations, so I was
wondering why not also provide a concrete implementation that
k2d2 provides, but change it to implement Chain's API, not the
one that k2d2 defines internally.

I guess that would be up to the k2d2 community, then. :)


The concrete implementations we have now are either minimal or based on published specifications, like the Servlet and Portlet APIs and JavaServer Faces. These are as much as proofs of concept as anything else.

I have wondered where implementations for more specialized usage might live. For example, a StrutsContext or ActionCommand (<brrr/>), or a Velocity Context that implemented the Chain Context, or likewise for the many other packages that implement a Context and/or a Command interface.

My inclination would be that they should live in the communities that can best support them. So if k2d2 wanted to base their implementation on Chain, then that implementation might be live in the k2d2 CVS. Likewise for implementations that catered to the Struts or Velocity communities.

-Ted.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to