Re: [Bug 6692] New: Remove Mode from the specification

Folks,

On 17 Mar 2009, at 05:13, Geoff Bullen wrote:

> Issue 6692 - WS-Eventing: Remove Mode from the specification
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692
>
> It seems the intent here is to remove the "mode" element from the  
> specification.  The main reason behind this seems to be that the WG  
> can't think of any reason to have it.  Mode seems to refer to  
> "transport" kinds of concepts - how things are delivered, whereas  
> Format refers to the format of what is delivered.  This makes  
> sense.  So the question is, do we need to be able to specify  
> transport concepts in Eventing, or do they all just compose in nicely?

Agreed, this is basically the question.

> The issue description mentions that complex queuing and distribution  
> can be supported without Mode, as can MakeConnection.  In terms of  
> MakeConnection, we should specifically talk about that as part of  
> issue 6432.  Certainly we cannot close on this issue before we close  
> on 6432.

To close (as proposed) on this one first, might simplify the decision  
on 6692, but they are not really linked. As long as there is a  
solution to 6432 that does not require a "Mode", the two issues are  
independent. MakeConnection is one solution and I can think of another  
following the pattern of PullPoint published in WS-Notification.

> As for the general need for a Mode, it is not clear to me at all  
> that other specs will just compose nicely on top of Eventing and  
> work without having to specify anything specific about them to the  
> Eventing Environment.

The basic reason for confidence here is that the delivery concept  
should be dealt with at a lower level in the stack, e.g. transport etc  
rather than in the eventing application.

>  Exactly how do you propose that a queuing system will interact with  
> Eventing?

A higher level specification (e.g. WS-BrokeredNotification) implements  
the queueing infrastructure and subscribes to the eventing source. The  
EPR simply contains the address to the queue input and the rest is  
done by queue implementation. This keeps the complexity out of the  
eventing spec, which I assume we want as simple as possible. Leaving  
Mode in encourages more complexity. Fore example, if we define a Mode  
for queuing, we would need a stack of parameters to control it.

>  How would a multicast solution work?

Again, the key is in the infrastructure. I subscribe to the source  
with an EPR specifying the multicast port I wish to use. The eventing  
application is completely protected from this complexity.

>  Can you provide a basic example of how you would imagine both of  
> these scenarios would compose (without using Mode)?

The rough guide is above, but you get the drift. The main aim is to  
simplify eventing. Leaving Mode in invites us to define a few common  
modes to ensure interoperability. This in turn encourages a lot of  
potential complexity, queuing parameters etc. When we have parallel  
composable technologies to handle these, why not use them. Mostly I am  
thinking WS-Addressing here.

> We believe that both of these (and also MakeConnection) will require  
> some knowledge and configuration during the Subscribe Request, and  
> if that is true, then the Mode element is the right place for those  
> extensions to be placed.

I think all that information should be invisible to the eventing level  
of the application. The transport layer should handle this and the EPR  
contains all the facilities we need. I will admit some guidance in a  
primer might be advisable. Simple specs (where there isn't a knob for  
every use case) have this need sometimes.

Geoff, thanks for the prompt. I was expecting to write this email at  
some time, now it's done :-) Talk to you all tonight.

>
>
> --Geoff
>
> -----Original Message-----
> From: public-ws-resource-access-notifications-request@w3.org [mailto:public-ws-resource-access-notifications-request@w3.org 
> ] On Behalf Of bugzilla@wiggum.w3.org
> Sent: Thursday, March 12, 2009 8:37 AM
> To: public-ws-resource-access-notifications@w3.org
> Subject: [Bug 6692] New: Remove Mode from the specification
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692
>
>           Summary: Remove Mode from the specification
>           Product: WS-Resource Access
>           Version: CR
>          Platform: PC
>        OS/Version: All
>            Status: NEW
>          Severity: major
>          Priority: P2
>         Component: Eventing
>        AssignedTo: public-ws-resource-access-notifications@w3.org
>        ReportedBy: david.Snelling@UK.Fujitsu.com
>         QAContact: public-ws-resource-access-notifications@w3.org
>
>
> The concept of Mode is redundant in the current version of the  
> specification.
> All events can be thought of as being delivered. There is no actual  
> definition
> of "Push Mode" and no other recommended modes. We even have a  
> MakeConnection
> strategy to allow clients behind NATs to fetch events. Likewise,  
> strategies for
> complex queuing and distribution are supportable without adding  
> additional
> modes and are outside the scope of this specification.
>
> Proposal: Remove /s:Envelope/s:Body/*/wse:Delivery/@Mode from the  
> specification
> and all references to Push Mode. A simple explanation of the  
> delivery idea and
> a pointer to some of the techniques available will be needed.
>
>
> -- 
> Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the QA contact for the bug.
> You are the assignee for the bug.
>
>
>

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe Limited
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE
     Reg. No. 4153469

     +44-7590-293439 (Mobile)







______________________________________________________________________
                                        
 Fujitsu Laboratories of Europe Limited
 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
 Registered No. 4153469
 
 This e-mail and any attachments are for the sole use of addressee(s) and
 may contain information which is privileged and confidential. Unauthorised
 use or copying for disclosure is strictly prohibited. The fact that this
 e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
 not guarantee that it has not been intercepted or amended nor that it is
 virus-free.

Received on Tuesday, 17 March 2009 09:46:57 UTC