Hi Ramesh, thank you very much for your feedback!
Yes it is not the optimal solution to implement something on a draft version. This is why we will not release it right away. We will perform the development on a separate branch and only merge once the draft version has been released. I think this has 3 advantages: 1. We can give feedback to the Oasis community about the draft version. This includes feedback on how easy it is to implement the Json metadata document and which features are missing from an implementation point of view. 2. It allows Kevin to act independent from our development within the server/client code. I think this is an important point as he is not dependent on features which are missing in the library and can start implementing right away. 3. Finally having such an isolated topic for a student has in my experience proven quite valuable as it reduces the amount of learning to understand the whole OData protocol before he can start working. WDYT? Best Regards, Christian -----Original Message----- From: Ramesh Reddy [mailto:[email protected]] Sent: Donnerstag, 19. März 2015 14:14 To: [email protected] Subject: Re: Requesting feedback for Implement OData Json Metadocument Serializer/Parser Project Proposal Kevin, Christian, As you guys know, the OData specification is not complete on the JSON based metadata document, so my advise is do not implement something that may give precedent in the community that it is official. Be cautious about that. Otherwise Kevin's proposal looks very detailed. Great job Kevin. Ramesh.. ----- Original Message ----- > Hi Olingo Community, > Please note now i have updated the proposal according to Christian's > feedback. > Regards > Kevin > > On Mon, Mar 16, 2015 at 7:41 PM, Kevin Ratnasekera <[email protected]> > wrote: > > > Hi Olingo community, > > As you might have seen from mailing lists I have been working with the > > project titled Implement OData Json Metadocument Serializer/Parser and > > hoping to participate this years GSoC with Apache Olingo. With the immense > > help from Christian, I was able to come up with a draft proposal for this > > project. I really appreciate if you could spend some time, provide me some > > feedback so that I could improve on it. > > > > [1] > > https://docs.google.com/document/d/1bUOfAevle7zXQ9DOD7EWHh147nRK0fDWxrywkd1RLGU/edit?usp=sharing > > > > Herewith I am including the feedback I received from Christian. > > > > OData Summary: > > The OData metadata is not only machine readable but also defined in a way > > that it is human readable. > > Services and Clients have to know about the protocol when they are > > implemented. This is why we provide a library which takes care of the > > protocol. This way a client or server can focus on the business logic. > > > > > > Detailed Description: > > I like that you understood the importance of a platform where no native > > XML parser is available. This is the case for Android development. > > But with version V4 there is a way in which clients can consume a payload > > which was requested with the odata.metadata=full header. > > But this causes each payload to become huge. To avoid this one can query > > the metadata once. > > Also there is already a released version of V4 which does not contain the > > JSON metadata document format. The current draft for the next released > > version does contain the new format. > > > > Scope: > > Very good. This sentence is very important. I would add that the scope > > should follow the draft version as there is no released version. > > > > Design server core lib: > > Perfect. That was what I was looking for! > > > > Design client core lib: > > I understand the current approach you documented and this is definitely a > > way to do it. > > Maybe we do not even need the SchemaDeserializer class as we use Jackson > > to deserialize the json document. so maybe annotations are enough in this > > case. This we will have to see. > > > > Implementation Approach: > > Unit test cases have to be provided within the phase where you implement > > code. So for example if you implement the JsonSerializer in phase 1 then I > > would expect that within that phase you also provide the unit tests for the > > serializer. > > The same goes for phase two where you implement the deserializer. > > > > Phase 3 should be reserved for documentation and integration tests only. > > We have an fit module where one can write such integration tests. > > > > You should also include some minor milestones within the phases. At least > > an estimate per big feature. For example you expect 3 days for entity types > > and complex types and another week for functions and actions. > > > > Community Presence: > > You can write there that we will schedule a video chat. > > > > Regards > > Kevin > > >
