Any comments? ----- Original Message -----
> Hi all, > @Ramesh: > Thanks a lot for your contribution (and push of it into the feature branch). > I created a separate JIRA issue for this extension feature -> [OLINGO-573]( > https://issues.apache.org/jira/browse/OLINGO-573 ) > As discussed before I can imagine that a more Framework like approach could > co-exist as separate module in Olingo (and hence a separate JIRA issue seams > to be a good idea). > Additionally we could “tag/flag” all commits with e.g. “[OLINGO-573]” to see > which commits belong to this. > Then I hope we get some discussion about this approach and find a good > solution how to integrate it into Olingo. > Kind regards, > Michael > > On 11 Feb 2015, at 18:29, Ramesh Reddy < [email protected] > wrote: > > > Dear Community, > > > Based on some discussions on the issue [1], there were several discussions > > merits of the Processor interface design and how it can be improved for > > sake > > of the service developer. Based on those discussions, I have implemented an > > alternative server side framework as extension. I added this in a separate > > branch called " olingo-server-extension" , you can also find it at [2] > > > - This framework currently does not remove any previous Processor > > interfaces. > > As extension, these can be evaluated side by side for comparison, then we > > can decide on the direction best for Olingo in integrating into one module. > > > - This framework designed specially to make the job of service developer as > > easy as possible to develop a OData service in the quickest time. > > > - Tries to enforce the odata specification rules, where they need to be, > > before service implementer receives the request for processing > > > - Moves Context URL processing away from service implementer > > > - Automatically works with registered serializers based on the > > "Content-Type" > > defined on the request > > > - Makes the building of response, based on request, such that it reflects > > the > > context of the request. Thus eliminates service implementer violating the > > spec expectations. > > > - Provides $metadata schema parser in server side, using which a service > > implementer can "define" their metadata of the service, rather than current > > method using the object form. > > > - Provides a full example based on TripPin service. > > > I encourage you take look at the example service in the test section of > > this > > module and see how a sample service can be developed. We are looking for > > your comments and suggestions to improve upon this framework and your > > support of the design to carry forward. Please do reply, even that is > > either > > a +1 or -1 > > > I understand that in this new framework, there single interface called > > "ServiceHandler" for service implementer to develop along with metadata. > > *If* multiple Processor interfaces is something we really do need, it is > > fairly straight forward and *easy* to extend the requests to use multiple > > interfaces as it is currently designed, so that any existing > > implementations > > are not broken. > > > Please take an hour or two looking through this and provide your feedback, > > and suggestions to improve upon. I sincerely appreciate your time. > > > [1] https://issues.apache.org/jira/browse/OLINGO-482 > > > [2] https://github.com/apache/olingo-odata4/tree/olingo-server-extension > > > Thanks. > > > Ramesh.. > > > http://teiid.org >
