I completely understand the constrain over here, However during the minor releases if we start to depreciate (Doc) and encourage to use the proper alternative, with the time we can get rid of these inconsistencies.
However, We should define these developer guide info in the doc. https://issues.apache.org/jira/browse/SYNAPSE-1037 On Fri, Jun 3, 2016 at 8:49 AM, Isuru Udana <isud...@gmail.com> wrote: > Hi Vanji, > > Thanks for sharing this idea. > > Changing these property names is a massive effort and will affect users as > well. > If we do so, as you mentioned we need to provide backward compatibility. > But that will add unnecessary overhead to the request processing and it > will make the code bad too. > > In the future we should try to avoid the usage of properties for > controlling the protocol level behaviours. > > So IMO, it is not worth to do this at this moment. > > Thanks. > > On Fri, Jun 3, 2016 at 9:46 AM, Vanjikumaran Sivajothy < > vanjikuma...@gmail.com> wrote: > >> Hi Devs, >> >> I am currently looking into the SYNAPSE-818, While going through with >> code, I notice inconsistency in the property naming across the board. >> >> These properties are following like CamelCap or camelBack or CAP_VAR, Why >> this much of variation?. I understand that SOAP headers and HTTP related >> headers could be exceptional. >> >> Example of inconsistency :- preserveProcessedHeaders, OperationName >> >> >> IMO, other properties that helps to control the flow should not vary in >> naming convention. So I am proposing to make it consistent across the >> synapse (Of course with backward compatibility). >> >> WDYT? >> >> [1]https://issues.apache.org/jira/browse/SYNAPSE-818 >> >> -- >> Best Regards, >> Vanji >> > > > > -- > *Isuru Udana* > Technical Lead > > > > > *; WSO2 Inc.; http://wso2.com <http://wso2.com>email: isud...@gmail.com > <isud...@gmail.com> blog: http://mytecheye.blogspot.com/ > <http://mytecheye.blogspot.com/>* > > > > -- Best Regards, Vanji
