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 <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
smime.p7s
Description: S/MIME cryptographic signature
