On Aug 27, 2006, at 10:50 PM, Jim Marino wrote:
Hmm, the converse to that is we have to put an XHost in the Tuscany
namespace for every type. I don't think this is that unmanageable
as OSGi does this.
I should clarify: I don't think having a separate project just for
the "host" interface is problematic.
The actual service implementation would be in the project for the
host, while the interface would be in a separate project which a
binding would depend on.
Jim
On Aug 27, 2006, at 10:44 PM, Jeremy Boynes wrote:
This sounds extremely fine grained, almost to the point of taking
modularity to the point of two, possibly three, projects per
service which I think is unmanageable.
We should keep the RMI binding as an extension for sure. But that
binding has an need for a physical service (RMIHost) whose
implementation should be provided by the host environment as only
the host knows how to create and schedule work from physical
endpoints (sockets).
We have a M-1-N situation here, multiplied by the potential number
of host services. I think we should keep all host interface
classes (like RMIHost and ServletHost) in host-api so that host
providers are at least aware of the host services extensions may
require (they always have the option of not implementing them).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
