I'm wondering whether it would be good to have a vote about this.
Of the five people who have expressed a view on this so far, four
of them have had a different first preference. In the interests
of making progress, I think it might be good to put forward a set
of options and vote to choose between them.
One question of clarification inline below.
Simon
Jean-Sebastien Delfino wrote:
Raymond Feng wrote:
I agree stability/compatibility is important. But we need to have a
good balance here. If we always sacrifice the architectural cleaness
to stability, we may end up with messy SPIs which will confuse our
new users. Especially for SPIs, they are used by extension developers
and embedders and (IMO) these types of users are more willing to use
the latest code base.
Simon Nash wrote:
I thought my proposal (see [1]) was a reasonable compromise that provided
stability without making too much of an architectural mess. There is a
one-time compatibilty hit to introduce the new approach, though. I'd be
interested to know what others think of this.
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL PROTECTED]
>>>> > Jean-Sebastien Delfino wrote:
> I'd like to propose two options:
>
> 1) Add methods to Invoker, mirroring what's described in the spec.
>
> interface Invoker {
>
> boolean allowsPassByReference();
>
> // and another similar method which we'll need to handle
> // non-blocking calls
> boolean isOneWay();
>
> }
>
> 2) or if we want to preserve binary compatibility for now, create
> interface Invoker2 extends Invoker {
>
> boolean allowsPassByReference();
>
> boolean isOneWay();
>
> }
>
My preference:
1. (1) above add a method to Invoker, and ask people on our dev and user
mailing lists if they have any issues with it.
2. (2) above and a plan to merge all these Xyz2 interfaces into the main
interfaces in the next major release.
By the "next major release" do you mean the 1.2 release that we recently
started discussing, or something else?
Simon
3. Simon's proposal [1], which introduces too much complexity IMHO.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
