RE: [sca-assembly] [Issue 80] Proposed directional resolution

["Eric Wells" <eric.wells@hitachisoftware.com>]

All,
    much as I think the Event Handling spec is pretty useful I have to agree
with Simon.

As Mike pointed out there are actually quite a few open issues now. I don't
think the current PRD/CD03 spec is a completely accurate reflection on what
the final document will look like.

If you add to this Event Handling the it will be too much work to deal with
in a reasonable time. (Do I need to mention TESTING it as well? :-}

Let's wrap up what we have in the 1.1 PRD and then think about how to add in
Event Handling.

Best Regards,
              Eric.


> -----Original Message-----
> From: Simon Nash [mailto:oasis@cjnash.com] 
> Sent: Monday, June 22, 2009 12:54 PM
> To: Anish Karmarkar
> Cc: OASIS Assembly
> Subject: Re: [sca-assembly] [Issue 80] Proposed directional resolution
> 
> Anish,
> I am very concerned about the work involved in fully 
> integrating the event concepts into SCA Assembly and 
> presumably all the other SCA specs.
> 
> At this stage in the SCA 1.1 lifecycle I believe our priority 
> should be to close down the few remaining issues, complete 
> the public reviews, and move to formal ratification of the 
> SCA 1.1 standard based on the current specifications.
> 
> Absorbing this major new piece of functionality into the SCA 
> specs will have large implications and push out the 
> completion of SCA 1.1 by some considerable time.  IMO it 
> would be better to look at whether the Events support could 
> be standardized in some other form such as a separate delta 
> or supplement to the SCA 1.1 base specs.  This would allow 
> the current specifications to achieve standardization in a 
> timely manner, followed by an SCA Events 1.1 standard when 
> this is complete and ready to go forward.
> 
>    Simon
> 
> Anish Karmarkar wrote:
> > I would like to propose that we use the contribution at [2], as a 
> > basis for a directional resolution for issue 80 [1]. 
> Specifically, we 
> > introduce the concepts of events, event types, producers, 
> consumers, 
> > channels; and the changes these concepts make to the existing 
> > composite/component/componentType/constrainingType constructs.
> > 
> > If this directional resolution is accepted, I suggest that 
> an inlined 
> > document (with change marks) be produced that provides a 
> merge between 
> > [2] and the existing latest version of SCA Assembly. This 
> would then 
> > serve as a basis for the resolution of issue 80.
> > 
> > Comments?
> > 
> > -Anish
> > --
> > 
> > [1] http://www.osoa.org/jira/browse/ASSEMBLY-80
> > [2]
> > 
> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php
> > 
> /32379/SCA_Assembly_Extensions_for_Event_Processing_and_PubSub_V1_0.pd
> > f
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the 
> OASIS TC that 
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > 
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS 
> TC that generates this mail.  Follow this link to all your 
> TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
>