RE: [issue 6432] - a modest proposal

See the previous notes on how its broken and not scalable - I'm partial to 
this one [1].  Sure anyone can code up any spec - that doesn't mean that 
its correct  :-)  people learn to work around quirk, bugs and 'issues' all 
the time, but that doesn't mean we have to live with them forever.

[1] 
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0016.html

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Geoff Bullen <Geoff.Bullen@microsoft.com> 
Sent by: public-ws-resource-access-request@w3.org
04/14/2009 03:02 PM

To
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
cc

Subject
RE: [issue 6432] - a modest proposal






Doug,
 
> As for "keeping A" - let's not forget that "A" is broken.
 
It is not clear to us what your definition of ?broken? is in this context. 
 From our understanding, solution ?A? has been successfully implemented, 
tested and interop?ed by hundreds of different implementers.  In those 
terms is it difficult to understand why you would call it ?broken?.  In 
the worst case one might describe solution A as ?adequate? or 
?successful?.
 
On the other hand, it would seem that Solution B has never actually been 
implemented, tested or interop?ed in the Eventing context.  Further, we 
are unaware of any implementer who has considered the use of the Mode 
attribute in Eventing to be a problem or to in any way inhibit their usage 
scenarios.  It should be noted that many of these implementers have 
successfully extended Eventing with new Modes.  Please also note that a 
number of current Eventing implementers, including Microsoft, Avaya, 
Fuji-Xerox and Odonata, have already voiced public concern to W3C over 
this new proposal (Solution B). 
 
--Geoff
 
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, April 14, 2009 6:09 AM
To: public-ws-resource-access@w3.org
Subject: Re: [issue 6432] - a modest proposal
 

I wouldn't describe the situation the same way.  I don't believe the 
proposal suggests that 
people keep 'A' - rather it simply offers it as an option for those who do 
not wish to change 
their code.  If I were starting from scratch with my implementation I 
would much prefer to 
have a single way of expressing how/where to send messages, not two. 
That's the 
more interoperable solution. 

As for "keeping A" - let's not forget that "A" is broken. People are free 
to continue to use it 
as they do today, as long as they understand the limitations. But WS-E 
itself should promote 
a solution that isn't broken and is consistent with the rest of the WS-* 
stack. 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 


Yves Lafon <ylafon@w3.org> 
Sent by: public-ws-resource-access-request@w3.org 
04/14/2009 05:44 AM 


To
Doug Davis/Raleigh/IBM@IBMUS 
cc
public-ws-resource-access@w3.org 
Subject
Re: [issue 6432] - a modest proposal
 








On Fri, 10 Apr 2009, Doug Davis wrote:

> Yves,
>  Actually, what you describe is what we have now.  We have two different
> ways of
> expressing how/where to send a message(s) within the same spec.  We're
> moving
> towards one way.  And, in doing so we're moving towards having it be
> consistent with
> all other WS-* specs.  Code reuse!  No specialized "message sending" 
code
> needed
> just for WS-Eventing.  That's even better for interoperability.

I am not talking about the quality of the solutions here. My point was 
that we currently have solution 'A' in Eventing, and the possibility of 
using solution 'B' using a mU trick. You propose to add in Eventing 
solution 'B' but keep 'A' and just add a mU to 'A'.
Regardless of what are 'A' and 'B', I see absolutely no gain wrt 
interoperability. We still have two different solutions that won't 
interoperate.


-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

        ~~Yves