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 >
