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
