On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <[EMAIL PROTECTED]>wrote: > > > On Mon, Oct 6, 2008 at 5:49 PM, ant elder <[EMAIL PROTECTED]> wrote: > >> >> >> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <[EMAIL PROTECTED]>wrote: >> >>> >>> >>> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <[EMAIL PROTECTED]> wrote: >>> >>>> >>>> >>>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <[EMAIL PROTECTED]>wrote: >>>> >>>> <snip> >>>> >>>> >>>>> I'm particularly interested in those who put the provider framwork in >>>>> place see the addition of binding configuration see this as an extension >>>>> of >>>>> the binding providers or see this as a new set of providers? >>>>> >>>>> >>>> This is looking like a new type of extension to me, people should be >>>> able to contribute new wireFormatters and have them made available for use >>>> within the Tuscany runtime. Its also looking like this should be possible >>>> to >>>> do at the application level. >>>> >>>> So Tuscany would come with a bunch of wireFormat extensions just like it >>>> already has a bunch of binding and implementation extensions. Something >>>> somewhere would define what the default wireFormat extension is to use with >>>> each binding when no <wireFormat> element is in the SCDL. So there would be >>>> a self contained JMS wireformat extension which implements the defaults as >>>> defined in section 5.2 in the JMS binding spec and you'd be able to do: >>>> >>>> <reference ...> >>>> <binding.jms> >>>> <wireFormat.jms/> >>>> </binding.jms> >>>> </reference> >>>> >>>> but that would be the default so the same as: >>>> >>>> <reference ...> >>>> <binding.jms /> >>>> </reference> >>>> >>>> Users could also do >>>> >>>> <reference ...> >>>> <binding.jms> >>>> <wireFormat.myFunkyFormatter/> >>>> </binding.jms> >>>> </reference> >>>> >>>> and have the 'myFunkyFormatter' extension as part of their application >>>> not some jar that needs to be added to the Tuscany runtime. >>>> >>>> We could use the definitions.xml file to define things like the default >>>> formatter for a binding, it also seems like that old discussion on using >>>> the >>>> definitions.xml file to declare the extensions would help with the >>>> myFunkyFormatter case as described at: >>>> http://apache.markmail.org/message/unubgkqdcwwch66m >>>> >>>> ...ant >>>> >>>> >>> So there are two points here then >>> >>> *1. wireFormat as a separate extension point.* >>> >>> Ok so that could work. We would need the usual provider structure for >>> wireFormat and operationSelection. Then we need some new bits to get the >>> associated interceptors in the right place. >>> >>> - A wire structure managed by the bindingListener/bindingInvoker >>> - some predefined "wire format" and "operation selection" phases on the >>> new wire that ensure that the interceptors get put in the correct place >>> - A mechanism where, as you suggest, the binding can instigate defaults >>> when no specifics are included in the SCDL. This could be as easy as >>> completing the model based on definitions.xml entries >>> - Code to read the model, select the appropriate factory and popoulate >>> the new wire with interceptors from the binding and from wireFormat and >>> operationSelector >>> >>> *2. extension points (wireFormat in this case) provided in SCA >>> contributions* >>> >>> Personally I'd like to keep this separate from 2 for the time being. Only >>> because it's easier in the first instance to go with adding extensions via >>> the META-INF/services mechanisms while we work out what the extension points >>> should look like. Having looked back over the ML conversation on >>> definitions.xml though it does seem that there was a desire to allow some >>> extensions to be added to the runtime as part of a contribution. We can't >>> even do this with policy today so something like wireFormat would be a >>> isolated case to look at. I still want to get the extension point right >>> first though. Doesn't stop others looking at this if they want to of course. >>> >>> >>> Simon >>> >> >> Do you mean do this with a stepping stone approach, so do (1) then do (2), >> or do you mean only do (1) and if someone out there in the community ever >> feels like contributing (2) then good for them and we'd probably take it? >> I'm asking because if users can't contribute a custom wireFormat then we'll >> need to provide a way to configure some Tuscany specific one, and if thats >> all we're doing how is that better than Tuscany's current approach of having >> some Tuscany specific attributes on the binding.jms element? >> >> ...ant >> >> >> > Yes, as a stepping stone. I was just presenting how I would approach it > while trying to make space for anyone who might have a real urge to get on > an look at the user provided extension point part. > > Simon >
Sounds good. ...ant
