I think it fits the rules we agreed ("standard" etc.) so I would say
yes, please do.
--
Jeremy
On 8/28/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
Hi Jim / Jeremy,
I put the RMIHost in the spi precisely for reasons that Jeremy pointed out.
Aslo with ServletHost already there I assumed that
Hi Jim / Jeremy,
I put the RMIHost in the spi precisely for reasons that Jeremy pointed out.
Aslo with ServletHost already there I assumed that this would be the way we
would go and hence put it there.
So now shall I move it over to the host-api?
Thanks
- Venkat
On 8/28/06, Jim Marino <[EMAI
On Aug 27, 2006, at 11:26 PM, Jeremy Boynes wrote:
Not every type - just those that we have tried to define a host
interface for. They will be in the Tuscany namespace anyway, it's
just a question of whether they are together in the host-api jar,
or spread amongst a load of other very smal
Not every type - just those that we have tried to define a host
interface for. They will be in the Tuscany namespace anyway, it's
just a question of whether they are together in the host-api jar, or
spread amongst a load of other very small jars.
How about we say that it's OK to add them to
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 i
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. The actual service implementation would be in the
project for the host, while the interface would be in a separate
project which a binding
On Aug 27, 2006, at 10:34 PM, Venkata Krishnan wrote:
Hi Jim,
I shall look into these rightaway. I shall move the RMIHost
interface
into the extension package itself.
I think that is problematic as it is likely to make host
implementations dependent on the extension project.
--
Jeremy
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
Hi Jim,
I shall look into these rightaway. I shall move the RMIHost interface
into the extension package itself.
I shall look into the exceptions and formatting as well.
- Venkat
On 8/28/06, Jim Marino <[EMAIL PROTECTED]> wrote:
I think we still have the same problem of piling everything
I think we still have the same problem of piling everything into one
project. We may wind up with a project having only one class (the
interface) but this may be the best solution since it avoids having
people update the Tuscany namespace with their extensions.
Jim
On Aug 27, 2006, at 10:0
Would host-api be the right place for RMIHost?
--
Jeremy
On Aug 27, 2006, at 7:28 PM, Jim Marino wrote:
I came across a couple of things related to the RMI binding today.
Venkat, when you get a chance, could you take a look at these?
- Shouldn't RMIHost be in a separate extension package ot
11 matches
Mail list logo
