On Tue, Jul 26, 2011 at 4:55 AM, Luciano Resende <luckbr1...@gmail.com> wrote: > On Mon, Jul 25, 2011 at 1:16 PM, ant elder <ant.el...@gmail.com> wrote: >> I've hacked some code together to support Cross-Origin Resource >> Sharing (CORS) which is newer replacement to JSONP (which we support >> with <binding.jsonp>) and i was wondering what the best place to put >> it is. I've tried in binding.http but that is a bit old now and hasn't >> really kept up with all the work in binding.rest, i've added it to >> binding.rest too but i don't really like the name REST in that binding >> and alll the old RPC function that it includes. So now i wondered if >> it was time for something new as we have talked about merging or >> replacing binding.http/binding.rest in the past so i wonder if it was >> time for something like a binding.jaxrs which has all the good new >> bits from binding.rest and http and then CORS could be supported with >> something like <binding.jaxrs enableCORS="true"> or maybe even have >> CORS enabled by default. >> >> Comments or preferences? >> >> ...ant >> > > What is the old RPC stuff that you want to remove from REST ? If you > are referring for the old Collection support, I'm +1 on cleaning up > that from REST binding. If you are referring to the different > operation selectors, then I believe we should leave it there as I have > couple scenarios that require that functionality. Having said that, I > really wouldn't like to create yet a 3rd binding. Is there a way we > can enable CORS as an optional operationSelector. >
I'll go add it as an attribute on binding.rest for now and we can see what thats like. I would quite like to keep it simple without needing extra optional config which is why it would be good to have it enabled by default and to not be something like an optional wireFormat or operationSelector. ...ant
